Vincent Parrett

It is possible to mitigate these attacks with signed packages and package signature verification. https://github.com/DelphiPackageManager/DPM/issues/19 https://github.com/NuGet/Home/wiki/Package-Signatures-Technical-Details Ideally a package would be signed by both the developer's certificate and the package servers's (in the case of a public repository). Nuget uses code signing certifcates, which is still a problem open source developers - they cost money and are next to impossible to get as individuals. You could also run your own package server in house and scrutinize each package uploaded before making it available to users. DPM's server does an av scan using clamav - I would like to use something more robust like virustotal but they have limits that cost $$ to increase to practical levels.

Ok, then my fallback answer for everything is 42 Antivirus - some av systems still do weird sh1t even when "disabled". Try adding explicit exclusions for your output folder for live. Also, it's still worth checking folder permissions, perhaps windows updates changed something. Where is the output folder?

Is your machine on an active directory domain? If so it's possible a group policy was applied that changed your permissions. Have a look at the permissions on the output folder.

I wasn't going to bring it up in this thread.. but since you opened the door... I've been working on one for a while now https://delphi.dev - but it's a big project for one person and I have a business to run and a family. Docs - https://docs.delphi.dev/ Source https://github.com/DelphiPackageManager Installer - https://github.com/DelphiPackageManager/DPM/releases (codesigned by VSoft Technologies Pty Ltd). It is working well, but I have yet to implement loading design time packages - the reason for that is a lack of spare time. I did redo the IDE user interface a while back and that part is much easier to use than before (modelled on Jetbrain's Rider nuget support) - I use it daily. DPM supports Delphi XE2 - 12.0 - which should make upgrading to newer delphi versions easy - if the packages you use are available for the newer version of delphi, just open your project in that new version (with dpm installed) and dpm will automatically download and install the packages required for the project (and update search paths accordingly). Packages can be hosted by a package server, or a directory (ie network file share). The website is also a package server - that part is working well, however the ui needs a lot more work so that users can create api keys for pubishing packages. Right now the only packages there are ones I forked and published. The website is an asp.net 8.0 application (because I have a lot of experience with it) with a react front end, using a postgresql db - running on ubuntu server on a vm on one of my servers in Sydney - not ideal for latency for the rest of the world - it is behind cloudfare but api routes are excluded (cloudfare does help as a cdn for the images and javascript). If interest in/usage of the server actually took off I would move it to a cloud host in the US to improve latency (that would require some funding). The actual package files are on a cdn (bunny.net) and are regionally cached, so once someone near you has downloaded a package it is cached on their edge and its fast to download. Right now that's not costing me much but if usage ramps up it would. I went with bunny.net purely because of pricing - but apart from the stupid name it's actually a pretty good service. Recently someone (thanks @Geoffrey Smith ) contributed a tool for creating dpm package definition files (json) and we have been working on that together (it's installed by default now). Geoff created this tool to ease creating package definitions for some commercial libraires he is using. I would love to see more interest in the project and welcome contributions.

No idea, I'm not from there.

https://www.ideracorp.com/brands No idea about the ownership structure

FYI, this forum is not owned or run by embarcadero.

Yep, I'm too lazy to type all those 1's and 0's - life's too short for that!

Thanks for taking the feedback on board. Some comments 1) Move the Readme to the root folder of the repo, that way it shows on github when you vist the repo. 2) Change the Netformat to Source or Src 3) Move the .groupproj to the Source folder. This is probably personal taste, but FStr might be confusing in Delphi code - especially for those coming to a code base and not being familiar with this library - since F is typically used to prefix class Fields. I understand why making it short is attractive.

Nice! I love seeing people think outside the box. I use string interpolation a lot in c# and I really dislike using Format in delphi. Some suggestions 1) Unit Tests - using DUnitX - not just a test application. 2) Prefix the Netformat.pas name with a namespace, eg VoSs2o0o.NetFormat.pas - this will avoid the chance that the unit name conflicts with other libraries ( the unit name is a bit generic). 3) TStr is not a great name for this, perhaps TFormatStr or TStringFormat or something like that would be more descriptive. 4) Restructure the repo to be more organised - see https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors 5) Hex format would be useful. Anyway, Kudos on a great idea.

Confluence is an abomination - full of security holes, new CVE's every week. Our instance has been hacked twice - both times by bitcoin minors, requiring us to build a new vm and restore from backup. We're close to completing our migration away from it thankfully. I'm not sure that Jira JSM is the right way to go, given that Embarcadero doesn't really do support 🤦‍♂️

Depending on what features you need and Delphi version you need, this might work for you https://github.com/VSoftTechnologies/VSoft.HttpClient (has a dependency on https://github.com/VSoftTechnologies/VSoft.CancellationToken).

No that would be pointless - restore from backup onto temp server.

We had the same issue last year, ordered a server in July, turned up in November. At least in our case, this was an upgrade not an emergency replacement. I have to agree - how hard is it to spin up a tempory vm on a cloud service - I suspect there is more to the story but we will probably never know.

Just clone the repo from bitbucket (with git) and use that.

Not sure what changes were made to parts other than Collections and Container - perhaps @Stefan Glienke can chime in here.

Just download v2, change your library/search paths and see what happens when you compile 😉

I guess it depends which features you are using, I did this a while back and only hit a few minor issues. I was mosly using the collections (and the IEnumerable<T> linq features) and the container.

Both the VCL and FMX are both designed to operate in the main thread only, creating/updating UI elements in another thread is quite likely to cause you problems.

The cloud isn't always cheaper (been there, done that, bought new servers). To make the cloud cheaper you really need to leverage the features they provide (not just a bunch of vm's) - and that means re-architecting things (=time + more money) and it also means vendor lock in - once you leverage the cloud features it's not easy to switch providers.

There are very few people left at Embarcadero that worked there in the 80s or 90s. A more likely explanation is that the people who know how all that stuff works are no longer there.. so people are afraid to touch it 🤔

Can anyone recommend a GRPC client library for delphi. I have had a quick look around and only found a 1 open source lib - https://github.com/ultraware/DelphiGrpc (no updates in 5 yrs), and nsoftware (which I will not buy as no source available). Any others I have missed (open source or commercial with source code).

I looked at sgcWebSockets today - but the price is really steep - I don't need the rest of the library but http/2 is only in the most expensive version - and then I need to get gprc working on top of that. I'm actually leaning towards doing this project in c# (the server is already c#) - testing with .net 8.0 AOT compilation so far produced a 4.5MB exe (+ a 12MB dll for google protocol buffers). Obviously it will be larger than that once done. As much as I want to use delphi for this project - the libraries are just not there - contrast to dotnet - grpc is a first class citizen (and the performance is impressive). I was able to get up and running in less than 10 minutes - contrast that to having spent most of today looking for a delphi grpc client that works.

I've been looking at that - since the DelphiGRPC makes use of it. Down the rabbit hole I go..

In the context of code signing, where do you get a pfx these days? the only certificates being issued are on tokens or HSM's, neither of which allow exporting the private key. We can debate the merits of the decisions taken with regards to the future of code signing but the reality is what we have in front of us right now... and that is what people are struggling with.