Leaderboard

Sonar is a widely used tool. This is the latest plug-in to use: https://github.com/integrated-application-development/sonar-delphi There are a handful of GitHub repos with sonar-delphi but this one has combined all the changes into one and is being actively developed. Kiuwan is a specific tool for application security and it is an Idera brand...but they don't support Delphi code scanning. I've asked them multiple times for Delphi support over the last few years, and it's always been 'on the radar' but no progress has been made as far as I can tell. https://www.kiuwan.com/ See their FAQ for programming language support: https://www.kiuwan.com/docs/display/K5/FAQs+-+Frequently+Asked+Questions I believe they do offer Exe scans... I don't recall as it's been a year or so since I last looked at them. The problem is that most of these advanced tools simply do not support Delphi and I haven't seen anyone else push to get support added. (Another example: https://docs.snyk.io/getting-started/supported-languages-frameworks-and-feature-availability-overview) There are companies out there where you can submit your Windows executable for runtime analysis. They typically charge for each scan. Most seem to be obscure, potentially hard to find, and expensive. I just did a Google search and found these potentials (which I haven't used at all and do not necessarily recommend - but it should get you started.) https://secureteam.co.uk/services/application-penetration-testing/desktop-application-security-assessment/ https://cobweb-security.com/service/desktop-application-security-assessment/ https://roundsec.io/desktop-application-security-assessment/ One of the old-school leaders of software analysis is "Understand" from https://scitools.com/ Here is their supported languages list, which includes Delphi: https://support.scitools.com/support/solutions/articles/70000582794-supported-languages If you are looking for general static code analysis, the best source for Delphi is: https://peganza.com/ You can use static code analysis tools like Sonar, Understand, Peganza to satisfy some security audits as well as they want you to have some automation to trigger anomalies and non-standard coding practices. The current trend is to build these tools into the IDE so that your code gets flagged for security issues while you are editing it and many of the obvious issues are mitigated before the code is committed. For Delphi, this includes Pascal Expert (https://peganza.com/products.html#PEX) and FixInsight (https://www.tmssoftware.com/site/fixinsight.asp) In general, some of the things to look for: https://owasp.org/www-project-desktop-app-security-top-10/

Hello, the Opencv 4.6 wrapper repository now has new examples, better Pascal classes, much better documentation. And instructions for compile on MacOS, too. Enjoy! Github repo https://github.com/gidesa/ocvWrapper46/

For those who still can't get enough, here is a very recent article from none other than Herb Sutter, of course with emphasis on C++ C++ safety, in context – Sutter’s Mill (herbsutter.com)

Konopka Signature VCL Controls (KSVC), formerly known as Raize Components and available via GetIt.

The TIcsMailQueue component is designed for exactly your requirement, you queue an HTML identically to your existing code, call the QueueMail method, and then let the component worry about delivering the email, in the background. You can queue hundreds of emails. Before queuing anything, you setup one or more SMTP servers, the background thread will then attempt to send queued emails to each of those servers multiple times over many hours until it is sent successfully, remove it from the queue and delete or archive the email. The sample has a window you can steal that shows queued emails, when they will be next attempted, and allows them to be deleted if never going to get delivered. Angus

To be more "simple: 1) You can refer in the "requires" section simple with IndyProtocols for example, but the library (bpl) used will be with "290" ... or the new extension for Delphi 11 or Delphi 13 ....; 2) So in every component will you refer in the future you'll refer ALWAYS to with "IndyProtocols" and depending of IDE version will linked to the correct BPL version (280, 290, 300, ....); This require the changes the name of the DPK/DPROJ files, the changes of the "requires" sections and the use of $LIBSUFFIX = AUTO (in the DPK and in the DPROJ files). In the past that was done using LIBSUFFIX (for example) with "290" instead of AUTO. The libraries in RAD STUDIO are related without suffix "290" but the BPL still have those suffix (for example you refer to RTL in the DPK files not RTL290). "NEW" WAY "OLD" WAY Bye

This can already be done, and has been possible since Delphi 1

The packages in Indy's GitHub repo are named with version-specific suffixes on each DPK/DPROJ file. The bundled Indy packages that ship with the IDE have been modified by Embarcadero to use LIBSUFFIX when compiled, so the version suffixes are omitted from the generated DCP files but not from the final BPL files.

For basic error / tamper detection a CRC would be easier and a lot faster since you can feed additional bytes into the calculation as the file grows. Can also keep a few length, CRC pairs around to re-check parts of the file as desired. The CRC value of the first 16MB could be used to either check the first 16MB of the file or to check from 16MB to another CRC at 20MB for example.

SHA1 is dead. I suggest using SHA2 or SHA3 even if it is "just" for a file checksum. If you want performance-optimized implementations I would suggest using mormot2. uses mormot.core.buffers, mormot.crypt.secure; ... HashFile(myFileName, THashAlgo.hfSHA256); Fun fact: mormot2 SHA256 is faster than RTL SHA1.

Yes. The code is in FidoLib (I collaborate in the project). The file is this: https://github.com/mirko-bianco/FidoLib/blob/develop/source/Json/Fido.JSON.Marshalling.pas

Hi, not using exit() is not the solution for me. Users use exit() when debugging a script. If to ProcessSystemExit; i add Py_DecRef(errtraceback); so the memory leak problem will disappear. The destructor TTerminalLogSettings will already be called. I have no idea, but how is that possible. procedure TPythonEngine.CheckError(ACatchStopEx : Boolean = False); procedure ProcessSystemExit; var errtype, errvalue, errtraceback: PPyObject; SErrValue: string; begin PyErr_Fetch(errtype, errvalue, errtraceback); Traceback.Refresh(errtraceback); SErrValue := PyObjectAsString(errvalue); Py_DecRef(errtraceback); // workaround PyErr_Clear; raise EPySystemExit.CreateResFmt(@SPyExcSystemError, [SErrValue]); end;

We use a lot of frames, but we almost always instantiate, reparent and connect them at runtime. Usually, we have a panel as a "host" for the frame, which lets the panel deal with the in-form alignment, so that the frame can use alClient. As @Davide Angeli mentions, loss of events has been a key factor for deciding to do it that way.

Can you shed some light on what a "SubForm" is? I am working with frames all the time. The IDE will show the wrong frames and throw error messages if you are opening project groups where the name of a frame class is not unique throughout all projects in that group. The IDE will often randomly redundantly copy parts of a frame on its container's .dfm file (even entire image lists). You will have to use your versioning system and watch carefully to commit only the parts you changed yourself, and not the random insertions by the IDE.

The biggest problem is when you create descendant forms (i.e. at design-time) where the ancestor contains frames. Otherwise, for me they're totally fine.

That doesn't help if you have multiple variables that refer to the same instance which I guess is a more likely scenario for double free.

it will also be enough if QP is operational by the time D13 arrives

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code. We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. Yes, my original post was sarcasm.

The whole thing started with this topic. Due to lack of possibilities, I wrote my own update mechanism which noes not rely on any advanced stuff but still should be versatile enough. Since the initial version TAEUpdater got some improvements and things are looking great. Some more stuff was implemented like hash-based verification, messages, E-tag caching, separate internal, development and production channels, ability to downgrade to a previous version, etc. I'm running it in my main application for a while and it seems to do the job correctly. Since not all of us might update from an unauthenticated web server, now 3 different file providers are shipped: HTTP, flatfile and custom. HTTP uses Delphi's TNetHTTPClient, flatfile reads the files from a local disk and custom has all necessary events exposed via events. I also got rid of some personal dependencies (like compressing the update file or using System.Zip2) and now everything is handed to the user for the solution to be more... generic. I still use my own version discovery and comparison method to be able to determine which published one is "newer" but that is going to be my next step. As a workaround, you can call .LoadUpdateFile, check the new version in each ActualProduct.Files and call .Update manually. What it needs: - An update file containing the product, all its files and versions. You can build this with TAEUpdateFile.SaveToStream in AE.Updater.UpdateFile.pas - Update packages, which can be zipped or encrypted, on FTP, HTTP, custom protocol - doesn't matter as events should be in place for performing all these actions Plans for the future: - Getting rid of more dependencies, maybe it'll become a standalone updater package with no extras - By accomplishing the above the code will get closer and closer to be truly cross-platform (atm it's WIndows only) - Get rid of modern stuff (like generics) and implement proper versioning conditionals so the package can be compiled and installed on anything other than D11.2 - Really, really basic documentation on how to use... Disclaimer: further changes are on their way. I'll possibly add / remove events / splitting the component in multiple subcomponents which might make existing .DFMs failing to be streamed. Also, publish your new versions on the Internal channel if I might break the core functionality 😞 All words as one - I just wanted to give the existing Delphi community a chance to implement auto-updating feature to their applications without having to pay for the component or the backend. Feel free to check it out. And suggest ways of improvement of course 🙂