VSoft Technologies Blogs

DPM Package Manager for Delphi - Beta

Mon, 01 Jun 2026 08:14:18 GMT

I've been working on a package manager for Delphi for a long time. I hit a roadblock and life got in the way and I couldn't find the time (or the motivation if I am honest) to work on it. I was using it every day, but it wasn't really usable for the masses. That was until recently..

Design time packages

That roadblock I hit was loading design time packages (bpl's). The early design decision to create separate dpm package files per compilerversion/platform made it really difficult to control which design time packages to load/unload and to get the order correct - failing to do so resulted in an unstable IDE at best.

Late last year I started on a redesign, using a single package file per compiler version. This simplified the design time bpl install story considerably. I've been chipping away at this redesign for a while now, adding a bunch of features along the way and completely rewriting the package server.

Note that this version is incompatible with the previously published Alpha releases - hopefully there will not be any more breaking changes.

What works

DPM is pretty much feature complete (for an initial release)

Creating packages (library authors)
Pushing packages to a package repository (directory or server)
Public package repository
Installing and Restoring packages, including dependencies and design time components.
Multiple package sources
Package Signing - both Author (code signing certificate) and Repository signing (automatic during upload).
Repository and Author Trust. You can decide which authors and repositories to trust.
SBOM generation - both CycloneDX and SPDX output formats.
Vulerability scanning via SBOM and osv.dev
CLI and IDE plugin.
Extensive documentation (still a work in progress but there is a lot there).

Supported Delphi Versions

Delphi XE2 to 13.1

I decided a long time ago that I wanted to support as many Delphi versions as possible - the idea being that DPM might make it easier for users to upgrade eventually. It's not easy - I'm constantly writing code that works on one version and doesn't on another. If DPM were just a CLI tool or a standalone UI tool, we could of course go back much further, but since the CLI and the IDE plugins share the core code, supporting versions earlier than XE2 became too difficult - either a lack of generics or generics bugs (of which there were plenty in early versions). My view is that those who are still using Delphi 7 are never going to upgrade, they are already happy with their lot and no likely to use DPM anyway!

What about C++ Builder and FPC/Lazarus

I would love to see support for both C++Builder and Lazarus - but simply do not have the time or expertise to tackle them myself - open to contributions - see Contributing before making a start on it!

How do I use it?

Download and install the client from github - The installer allows you to install for the current user, or for all users (requires elevation to install). It installs both the CLI and the IDE plugins for the versions of RAD Studio you have installed.

Once a project is loaded in the IDE, you can access the DPM editor view via the Project tree (right click on a project or project group, Manage DPM Packages), or via the Project menu. There is also a toolbar button you can add to your toolbar.

The DPM editor view presents a list of available packages, click on one to highlight it, then at the top right you can click on the [+] button to install the package. You can choose the version to install, and whether to install it for all projects in the group, or just specific projects. DPM will download the package and any of it's dependent packages, build them (in the correct order) and add them to your project's Search Path - ready to use. If the package has any design time components, those are loaded into the IDE at the same time. The next time you open the project, the DPM Restore process will run, ensuring that any referenced packages are installed, if any are missing (like for example when you open the project on another machine) - it will automatically download and install them.

You can filter, search the package list to find packages you want (of course there are not many packages available yet) - by default pre-release packages are not shown, check on the pre-release option to show them.

When newer versions of packages become available, you can upgrade them in the IDE - the upgrade button will show when you select a package with an upgrade available.

New Features

As part of this overhaul, we added a few new features

Package Signing

Package signing provides a mechanism for ensure package Integrity, Authenticity and Provenance.

Package authors can (optionally) sign their packages with a Code Signing Certificate, by using the `dpm sign` command after packing - using a pfx file (although those are rare these days), using a usb token (will prompt for pin/password) or using Signotaur (with v2 coming soon) or Azure Key Vault (untested at this stage).

The public package repository also signs the package when it is uploaded, if an Author Signature is present then it is referenced by Repository Signature that is added to the package.

If some opens the package locally (it's a zip file) and adds or removes files, then that will invalidate the signature(s). If someone removes the signatures - then that package's authenticity, integrity and provenance is no longer assured.

Author and Repository Trust

On the client side, you can add Authors and Repositories to a trust list. By default the public repository is trusted.

Signature Downgrade Protection

DPM remembers whether a package was previously signed. If a later version of the same package shows up unsigned, that is suspicious - either an attacker is trying to substitute a malicious package, or the publisher has lost their signing key. The default setting on the client for this is prompt - the user will be prompted to continue installing the package.

The package server also adds signing downgrade protection. If the author uploads an unsigned package that was previously signed in earlier versions, that upload will fail. The author can of course acknowledge the downgrade on the server and re-upload the package.

Whilst Package Signing and Author/Repository Trust will not stop all supply chain attacks from happening, it is at least a small part of the solution. We would welcome suggestions on where this can be improved

Software Bill of Materials (SBOM) Generation

The `dpm sbom` command will generate an SBOM for a project or project group - both CycloneDX and SPDX formats are supported. An HTML report is also produced for human consumption.

Vulnerability scanning

The `dpm scan [options]` command will scan either a CycloneDX SBOM or a project/projectgroup and check it against the Open Source Vulnerabilities database at https://osv.dev

Organisations

On some projects, more than one person might be allowed to publish packages. For this reason you can create an Organisation, and invite other users to join. This then allows them to publish under that organisation's name. It also makes life easier when a new maintainer takes over a project (just add them to the organisation).

We have created organisations for some projects already, with the view that when the original project maintainers get on board with dpm (we hope) we can add them to the organisation and allow them to take control over it.

Reserved Prefixes

This is a server side feature that allows us to protect against people publishing packages that look as though they might come from another user. As an example, we publish our packages with the prefix VSoft.

e.g VSoft.DUnitX, VSoft.AnsiConsole

With the the reserved prefix no one else can publish a package with the prefix VSoft.

They can of course publish their version of DUnitX with a different prefix - e.g MyUser.DUnitX

We have added reserved prefixes for a bunch of well known libraries/authors - if you are one and get an error when trying to publish packages then contact us so we can assign the prefix to you. Our hope with this feature (and us preemptively adding well known prefixes) is that it will cut down on package name squatting.

Creating Packages

You might want to create packages if :

You have a library you want to share publicly or privately
You have a third party vendor libraries you want to standardize for internal use

Note that we do allow the publishing of commercial and trial/evaluation packages, provided they are flagged as such in their dspec.yaml

The process is the same for both, only the publishing part is different.

The first step is to create a package spec yaml file that defines the package and what it contains - e.g MyOrg.MyLibrary.dspec.yaml

You can point the `dpm spec` command at your source folder, and it will attempt to scaffold a package spec file for you. It won't be usable immediately - but it will give you a head start.

Once your dspec.yaml file is fully defined, use the `dpm pack MyOrg.MyLibrary.dspec.yaml -o=c:\mypackagesfolder` command to create the package files. The output be a .dpkg file for each compiler version your package supports.

The next step (optional) is to sign the .dpkg files using a code signing certificate/

Test the package locally to make sure it installs correctly. To do this, create a package source (`dpm sources add` command or from the IDE options) that points to your package output folder (the one you used in with pack command).

If it fails, fix the dspec, pack it again, remove the package folder from the package cache (e.g `dpm cache remove MyOrg.MyLibrary -c 13.0 --version 1.2.0`) and try again.

The final step is to publish the package - this is done using the `dpm push` command.

If you are creating packages for internal use, you can just copy the files into the shared directory, however it is better to use the dpm push command - this speeds up usage of that directory as a package source (it extracts the icon, spec and writes the hash).

If you are creating packages to share on delphi.dev then you need to follow a few steps.

1) Register on delphi.dev, enable 2 factor authentication.
2) Optionally create an Organisation (useful if you have a team creating/managing packages.)
3) If you signed your packages - register the public key on your account under "signing keys" (or org signing keys for an organisation).
4) Create an API Key - specify the package owner (yourself or your organisation)

With that done, use the `dpm push -source=dpm` command to push your packages to the dpm server.

If all goes well, the packages will show up in the dpm clients and website in a few minutes. They do first undergo some validation, virus scanning, repository signing before they are uploaded to the cloud storage.

Infrastructure

The delphi.dev site is hosted on our servers in Sydney, Australia. The site runs on a Proxmox virtual machine (linux) in a few docker containers, managed by Dokploy. It uses a Postgresql DB (also in a container) and ClamAV (again in a container). The site is behind CloudFlare - with aggressive caching - we hope that will offset the latency that hosting downunder causes for the rest of the world. If this project garners enough support and donations (which we will enable at some point) to afford hosting elsewhere - we can quite easily move to a host somewhere more central (where most of the user are).

The package files themselves are stored on CloudFlare R2 storage (US East) - which also does caching - the more people use dpm the faster downloading packages will become.

DPM Clients also cache downloaded packages, so it avoids downloading package files every time you use a package on another project.

Is it finished?

Is any software ever really finished or perfect? DPM is currently in BETA, that means it's mostly feature complete - we're still tinkering around the edges, fixing bugs and improving performance - but it's relatively stable. We're using it here for FinalBuilder and Automise and on our CI servers. I encourage all Delphi developers to give it a go. I especially encourage library authors to take a look and consider creating packages for their libraries.

DPM won't work for everyone or every project or every organisation - but it should work for most. One thing to note, DPM makes minimal (and easily removed) changes to your dproj files, and it will work alongside any third party libraries you already have installed.

As always, feedback is welcomed.

Website : https://delphi.dev
Client downloads : https://github.com/DelphiPackageManager/DPM/releases/latest
Client source code : https://github.com/DelphiPackageManager/DPM
Server source code : https://github.com/DelphiPackageManager/DPMServer

FinalBuilder 8.6 and Automise 5.6 Release

Tue, 26 May 2026 03:44:40 GMT

Today's release of FinalBuilder 8.6 and Automise 5.6 is important if you use the SFTP actions in these products.

This release includes re-implemented SFTP actions, in native code, using a new SFTP client library. This is something we have been wanting to for a few years now, the old library was no longer fit for purpose - it had bugs we were never able to resolve (since we never had the source code) and it did not support the newer algorithms.

The actions have been tested with

- OpenSSH 10.x
- Bitvise 9.x

In addition we added support for newer Post Quantum key exchange algorithms :
- mlkem768x25519-sha256
- sntrup761x25519-sha512@openssh.com

IMPORTANT: Before installing/running this release, ensure you have a backup of your project files (even better if they are in version control!). Project files saved with this version cannot be opened in older versions without information loss.

Whilst we have done extensive testing, it was not possible for us to test with every SSH server implementation out there - so there may be issues. We suggest you test this version with your SSH server(s) before putting this version into production.

Signing .rdp files with Signotaur (and surviving the April Windows update)

Fri, 24 Apr 2026 02:27:48 GMT

In this article:

What changed for signed .rdp files in the April 2026 Windows update
Why previously-working signatures now show an orange warning dialog
The registry policy recipient machines need for no dialog at all
How Signotaur signs .rdp files without distributing the certificate
Deploying the policy via Group Policy or PowerShell

If you push Remote Desktop shortcuts out to users, you probably already know about the April 2026 Windows cumulative update (KB5083769 on Windows 11, KB5082200 on Windows 10). If you don't, you might have found out the hard way — via a Monday-morning deluge of "is this a virus?" tickets from users who suddenly have a big orange warning on the RDP file that worked fine last week.

Signotaur 1.2.0.107 ships with .rdp file signing support. Here's what changed in Windows, why it matters, and what the new signing command actually does.

What Microsoft changed

The April cumulative addresses CVE-2026-26151. Two user-visible things came with it:

The Remote Desktop Connection warning dialog was redesigned. It now lists every resource the connection can redirect (drives, printers, clipboard, USB, etc.) with individual checkboxes, and every box is off by default. Users have to opt in to each one on every connection, every time.
The trust criteria for signed .rdp files tightened. Pre-April, a file signed by an untrusted cert got a yellow "Verify the publisher" banner. Post-April, the same file gets an orange "Caution: Unknown remote connection" banner — visually indistinguishable from an unsigned file.

Here's what the new per-launch dialog looks like. For an unsigned file:

And for a file signed by a publisher Windows can verify:

Separately, the first time any user opens an .rdp file after installing the update, Windows shows a one-time educational dialog explaining what .rdp files are and why they can be dangerous:

Once dismissed, it doesn't reappear for that account.

Discussion and lament: r/sysadmin: FYI: Microsoft RDP changes with April cumulative.

This is a genuinely good security change — the old dialog was vague and under-informed users about what was being shared with the remote host. It is also a rather annoying deployment change, because plenty of teams had rdpsign.exe-signed files quietly working for years, and now they don't.

Why people got caught out

The usual story goes like this: a team signed their .rdp file years ago with a self-signed or internal-CA certificate, shipped it to users, and it displayed a friendly yellow "Verify the publisher: Acme Corp" dialog that everyone clicked through. After April's update, the same file suddenly shows an orange "Unknown remote connection" dialog and support gets flooded. One representative example from the Reddit threads: a sysadmin describing exactly this.

The signatures on those files are still cryptographically valid. Windows is just stricter now about what counts as a "verified publisher" for RDP.

The actual recipe (no dialog at all)

Cutting through the noise, here's what recipient machines need for a signed .rdp file to open with no warning dialog at all:

The signing certificate's chain must terminate in a root the client machine trusts. Commercial code-signing certs (DigiCert, Sectigo, etc.) chain to roots Windows already trusts. For an internal CA or self-signed cert, the root has to be imported into Cert:\*\Root on each client.
A Remote Desktop trust policy must be in place that whitelists your signing certificate's SHA-1 thumbprint. This lives at either HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (machine-wide, requires admin) or HKCU\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (per-user, no admin required), and needs two values:
- AllowSignedFiles — REG_DWORD, set to 1
- TrustedCertThumbprints — REG_SZ, the SHA-1 thumbprint of your signing cert, uppercase, no spaces (semicolon-separated if you have more than one)

A word of warning about one trap we hit: TrustedCertThumbprints is a whitelist on top of normal chain validation, not a replacement for it. Dropping a self-signed cert's thumbprint into the list without also importing the cert into a trusted root store does nothing. If you've tried this and wondered why it didn't work, that's why.

What Signotaur does when you sign a .rdp file

Unlike rdpsign.exe, Signotaur signs .rdp files against a remote server — the private key stays on the server (or an HSM it's connected to), so no admin workstation or automation host needs a local copy of the signing certificate. This is the main reason to use Signotaur for .rdp signing rather than running rdpsign.exe directly.

The mechanics otherwise match what you'd expect. The client reads the .rdp file, canonicalises the contents, sends only the digest to the server for signing, and writes the signed file back in place. The output is byte-equivalent to rdpsign.exe's — same canonical form, same 12-byte Microsoft wrapper, same detached CMS structure — so recipients see the same Windows Remote Desktop Connection dialog regardless of which tool produced the signature.

RFC 3161 timestamping is supported, and the timestamp is embedded into the CMS in the standard way. But there's a caveat that's easy to miss: mstsc.exe doesn't actually consult the timestamp when validating a .rdp signature — it only checks whether the signing certificate is currently valid at the moment the file is opened. The strongest indirect evidence for this is that Microsoft's own rdpsign.exe has no timestamping support at all — no /tr flag, no timestamp in its output.

The timestamp is still worth having: it's standards-compliant CMS so general-purpose tools can read the signing time, it provides a tamper-evident audit trail, and it future-proofs against any future change in mstsc's behaviour. In practice though, plan to re-sign distributed .rdp files when your signing certificate is renewed, the same way you would for an unsigned-but-distributed file.

Because the registry recipe above is easy to get wrong, Signotaur also prints the recipe for you after signing, pre-filled with the thumbprint of the certificate that just signed the file. It tells you whether the cert is self-signed (in which case you'll also need to deploy the cert itself to recipient trusted-root stores) or chained (in which case you may not).

If you're running sign interactively on Windows, it also offers to apply the policy to HKCU for the current user on the spot — no admin rights needed, no registry editor, no PowerShell snippet to copy-paste. This is mostly useful for confirming the signing works locally before you deploy the policy via GPO. In unattended runs, the prompt is automatically skipped, and you can pass --no-mstsc-guidance (--nmg) to suppress the whole lot if the log gets noisy.

An example

The sign command detects .rdp files automatically based on extension, so there's nothing special to type:

	
			SignotaurTool.exe sign -a  -s  -t  --tr http://timestamp.digicert.com --td SHA256 connect-to-prod.rdp

After a successful sign you'll see something along the lines of:

RDP signing guidance (Windows Remote Desktop Connection compatibility, post-KB5083769):

By default recipients will see a "Verify the publisher" or "Unknown publisher"
warning dialog when opening this signed file in Windows Remote Desktop Connection.
To eliminate the warning, each recipient machine needs:

1. The signing certificate's chain trusted on the machine.
   For commercial certificates chaining to a Windows-preinstalled root, no action
   is required; internal-CA certificates require the CA to be imported into each
   recipient's Trusted Root store.

2. The signing certificate's thumbprint added to the Remote Desktop trust-publisher
   policy:

   Value: AllowSignedFiles (REG_DWORD) = 1
   Value: TrustedCertThumbprints (REG_SZ) = 

Apply AllowSignedFiles + TrustedCertThumbprints to your current user registry now?
Useful for testing this signed .rdp locally. [y/N]:

Answer y and it writes the values to your HKCU — open the file in Remote Desktop Connection, confirm there's no dialog, and you know the signing bit is working before you take the policy near a GPO.

Deploying the policy to the fleet

For anything beyond a couple of machines, Group Policy is the right tool — it's also how you set these same values without touching the registry by hand. In the Group Policy Management Editor:

Computer (or User) Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client
Allow .rdp files from valid publishers and user's default .rdp settings → Enabled
Specify SHA1 thumbprints of certificates representing trusted .rdp publishers → Enabled, with your thumbprints in the list (uppercase, semicolon-separated if multiple)

Intune has equivalent settings under the Administrative Templates profile. If you're deploying to a smaller set of machines, or scripting it, a PowerShell snippet that does the per-user version (no admin needed) looks like this:

	
			$p = 'HKCU:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $p -Force | Out-Null
Set-ItemProperty -Path $p -Name AllowSignedFiles -Value 1 -Type DWord
Set-ItemProperty -Path $p -Name TrustedCertThumbprints -Value 'YOUR_THUMBPRINT_UPPERCASE' -Type String

Swap HKCU for HKLM for the machine-wide version (and run elevated). The thumbprint must be uppercase with no spaces; use a semicolon to join multiple thumbprints if you have more than one signing cert in rotation.

What you still can't do

A few things worth knowing up front so you don't hunt for them:

The per-redirection checkboxes in the new dialog are not controlled by AllowSignedFiles. Even with a properly trusted and whitelisted signature, users still see the redirection dialog on first use. There's a separate set of policies for which redirections are allowed on the server side; the client-side checkboxes are a user-consent UI rather than a trust decision.
There's a temporary "revert to pre-April dialog" switch at HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client\RedirectionWarningDialogVersion = 1. Don't rely on it — Microsoft has been explicit that it will be removed in a future update.
Windows has no built-in .rdp signature verifier. rdpsign.exe /v is "verbose", not "verify"; in practice the only verifier is Remote Desktop Connection opening the file. Signotaur's verify command will validate the signature and cert chain offline if you want a CI-friendly check.

If you'd rather not think about any of this

The short version: get a code-signing certificate from a public CA that chains to a Windows-preinstalled root, register it with your Signotaur server, sign your .rdp files as part of your distribution workflow, and push the AllowSignedFiles + TrustedCertThumbprints policy out via GPO. After that, signed .rdp files open with no dialog, and the next time Microsoft tightens the rules you've already done the trust-deployment work.

For command-line details and the full signing command reference see the Signotaur documentation. If you run into something specific — especially if you have an internal CA or a less-common PKCS#11 token in play — our support team is happy to help.

Managing Certificate and API Key Expiry with Signotaur

Fri, 13 Mar 2026 03:18:12 GMT

In this article:

Why code signing certificates now expire sooner
How certificate labels remove thumbprints from build scripts
How to rotate and renew API keys safely
How to automate the process in Continua CI

Shorter Certificate Lifetimes Are Coming

Code signing certificates used to last up to three years. As of March 1, 2026, that is no longer the case.

The CA/Browser Forum adopted Ballot CSC-31 on November 17, 2025, reducing the maximum validity period for publicly-trusted code signing certificates from 39 months to 460 days (roughly 15 months). For most teams, that means certificate renewals are now an annual operational task rather than an occasional one.

When a certificate is renewed, it receives a new thumbprint, and build scripts that reference the old thumbprint must be updated. In large CI/CD environments, tracking down every reference can be tedious and error-prone.

Separately, API keys used by CI agents to authenticate with the signing server have their own lifecycle and eventually need to be rotated. Replacing them without interrupting active build pipelines can be challenging.

Signotaur addresses both concerns. Label-based certificate selection decouples build pipelines from individual certificates, while API key rotation with overlap allows credentials to be replaced without downtime. Together they turn what used to be stressful maintenance tasks into routine operations.

Certificate Labels: Automatic Certificate Rotation

The Thumbprint Problem

Traditionally, build scripts reference a code signing certificate by its SHA-1 thumbprint — a 40-character hex string that uniquely identifies the certificate. When you renew, you get a new certificate with a new thumbprint, so every script that signs code needs to be updated. If you sign across multiple CI configurations, that means tracking down and editing each one.

Labels to the Rescue

Signotaur lets you assign a label to each registered certificate — for example, production or nightly. When you request a signing operation by label instead of thumbprint, Signotaur automatically selects the certificate with the latest expiry date among all enabled, non-expired certificates that share that label. This ensures that newly issued certificates automatically take precedence.

The rotation workflow is straightforward:

Register your renewed certificate and assign it the same label as the outgoing one.
Builds automatically pick up the new certificate — no script changes required.
The old certificate expires naturally; remove it from Signotaur when you're ready.

Expiration Monitoring

Signotaur's background monitoring service checks certificate expiration daily and sends email notifications to administrators at configurable intervals. The defaults are 30, 14, 7, 3, and 1 day(s) before expiry, with an additional alert if a certificate has already expired. You can customise these warning thresholds in the server configuration.

During a rotation window — when both the old and new certificates are registered with the same label — the admin UI highlights the duplicate label so you can confirm the overlap is intentional.

API Key Rotation with Overlap

Why Rotate Keys?

API keys grant access to your signing service. If a key is leaked or reused indefinitely, it becomes a long-lived security risk. Regular rotation limits the impact if a key is compromised, satisfies compliance requirements, and handles natural key expiry gracefully. But naive rotation — revoke old, issue new — creates a window where CI agents holding the old key start failing.

How Signotaur Handles It

The rotate-key command creates a new API key while keeping the old one valid for a configurable overlap period of 0–30 days (default: 7 days). During this window, both keys are accepted, allowing CI agents and environments to transition without interruption.

Once the overlap period expires, the old key is automatically revoked. If you prefer to manage revocation manually, pass --no-auto-revoke and the old key will remain valid until you explicitly revoke it.

Safety Guardrails

Role required — users must be assigned the ApiKeyRotator role before they can rotate keys. An administrator can assign this role in the Signotaur admin UI.
Rate limiting — a maximum of 5 rotations per user per 24-hour period prevents accidental key sprawl.
Linear chain only — a key that has already been rotated cannot be rotated again; you must use the successor key. This prevents branching into multiple active key chains.
Proactive expiry checking — the sign command accepts a --fail-if-expiring-within flag (e.g. 14d). If the API key used for signing will expire within that window, the command fails immediately with a clear message — catching the problem in CI before it causes a real signing failure.

Conditional Rotation

The --if-expiring-within flag on rotate-key makes rotation idempotent: the key is only rotated if it expires within the specified duration (e.g. 14d, 1w, 24h). This makes it safe to run rotate-key on every CI build or on a nightly schedule without generating unnecessary keys.

Example scheduled rotation command:

signotaur rotate-key --if-expiring-within 14d

Key Renewal

By default, a rotated key inherits the old key's expiry date. If the old key had 30 days of validity remaining, the new key also expires in 30 days. Over time, repeatedly rotating a key gradually shortens its remaining lifetime — which can be a problem for long-running automation.

The --renew flag gives the new key a fresh validity period starting from the rotation date, rather than inheriting whatever time was left on the old key. Without a value, it uses the server default of 90 days; with a value (e.g. --renew 180d), it sets a specific duration up to a maximum of 365 days.

This pairs naturally with conditional rotation — check whether the key is approaching expiry, and if so, rotate and renew in a single command:

signotaur rotate-key --if-expiring-within 14d --renew

If the renewal duration would be shorter than the old key's remaining validity (for example renewing for 30 days when 60 days remain), the command fails as a safety measure. Pass --allow-validity-reduction to override this check when the shorter duration is intentional.

Putting It Together in Continua CI

Continua CI ships dedicated Signotaur actions for both signing and key rotation, so you can wire up the entire workflow without writing any custom scripts. Before configuring those actions, you'll need to assign a label to your certificates in the Signotaur admin UI.

Assigning a Label to Your Certificates

In the Signotaur admin UI, navigate to Certificates and either add a new certificate or edit an existing one. In the certificate dialog you'll find two name fields:

Alias — a unique display name for the certificate (auto-generated by default, e.g. "CodeSigningCert (2027-12-31)").
Label — an optional identifier used for CLI and CI/CD certificate selection, e.g. production. Multiple certificates can share the same label. Matching is case-insensitive, so Production and production resolve the same way.

When you renew a certificate, register the new one and assign it the same label as the outgoing certificate. The admin UI will show an orange notice confirming that multiple active certificates share the label and that the one with the latest expiry will be selected automatically. No build script changes needed.

For full details, see the Certificates documentation.

Setting Up the Rotate Keys Action

Add the Signotaur Rotate Keys action to a stage — either in a scheduled maintenance configuration or directly in your build configuration. With the If Expiring Within condition the action only rotates the key when expiry is approaching, so it can safely run on every build.

The action is organised into several tabs:

Signotaur Rotate Keys tab — configure Overlap Days (how long the old key remains valid alongside the new one, default 7) and whether to Disable auto-revocation if you prefer to revoke old keys manually.

Server tab — set the Server URL for your Signotaur instance and the API Key Source. Select Value (from variable) and reference a server variable (e.g. %SignotaurAPIKey%) to avoid hard-coding keys in the action.

Conditions tab — set If Expiring Within to make the rotation conditional (e.g. 14d to only rotate if expiry is within two weeks). Enable Ignore already rotated error to safely run the action in concurrent CI builds without failure if the key was already rotated by another build.

Renewal tab — enable the Renew checkbox to give the new key a fresh validity period instead of inheriting the old key's remaining lifetime. Set a specific Renew Duration (e.g. 90d), or leave it blank to use the server default. Check Allow validity reduction if the renewal duration may be shorter than the old key's remaining validity.

Output tab — choose Set Variable as the output destination and select a Server variable to store the new key. This way your sign actions automatically pick up the rotated key without any manual updates.

Full documentation: Signotaur Rotate Keys Action

Setting Up the Sign Action with Label Selection

Add the Signotaur Sign action to your build stage, after compilation and before packaging.

Key fields:

Files to Sign — glob patterns for your build output, e.g. **/*.exe, **/*.dll.
Certificate Selection Mode — set to Label.
Label — your shared label, e.g. production. Signotaur will automatically select the certificate with the latest expiry date.
API Key Source — point to the server variable populated by the Rotate Keys action, or a securely stored key.
Fail If Expiring Within — e.g. 14d. If the API key expires within two weeks, the action fails early so you can rotate before it becomes a blocker.
Timestamp Server & Digest — configure your preferred timestamping authority and hash algorithm.

Full documentation: Signotaur Sign Action

Typical Rotation Workflow

In practice, certificate and API key rotation can be handled with a small amount of scheduled automation in your CI system.

Register renewed certificates in Signotaur and assign them the same label as the previous certificate.
CI builds continue using the label, automatically selecting the certificate with the latest expiry date.
Schedule periodic API key checks using the rotate-key --if-expiring-within option.
The new key is written to a CI server variable, allowing build pipelines to automatically use the rotated key.
Use --renew so rotated keys receive a fresh validity period rather than inheriting the old key's remaining lifetime.
Retire old certificates and keys once they are no longer needed.

Wrapping Up

With code signing certificate lifetimes dropping to roughly 15 months, the days of "set it and forget it" certificate management are over. Signotaur's label-based signing means your CI/CD pipelines don't need to know — or care — which specific certificate is current. And overlap-based API key rotation ensures you can swap credentials without any signing downtime.

These features are already available in Signotaur. If you're evaluating it, check out the Signotaur documentation to get started.

Black Friday Sale 2025 - 40% off all new licenses - Extended!

Sun, 23 Nov 2025 23:20:19 GMT

Black Friday Sale - 40% off all new licenses until midnight (utc) 9th December 2025.

No coupon code required, the store will apply the discount automatically.

ClickOnce and VSTO Application Signing with Signotaur

Tue, 14 Oct 2025 00:23:40 GMT

If you've been working with ClickOnce or VSTO applications, you know that signing them isn't quite like signing a regular executable. We're pleased to announce that Signotaur now handles ClickOnce and VSTO application signing, taking care of the manifest orchestration so you don't have to.

What Makes ClickOnce and VSTO Different?

When you sign a standard executable or DLL, you're dealing with a single file. The process is straightforward: calculate a hash, sign it, embed the signature. One file, one operation.

ClickOnce and VSTO applications are a different beast entirely. These deployment packages consist of multiple files tied together by manifest files that describe the application structure, dependencies, and deployment configuration. The challenge? Everything needs to be signed in a specific order, and those manifests need to be updated with new hash values after each signing operation.

Here's what's happening under the hood:

Application files get signed first (your assemblies, dependencies, etc.)
The application manifest (.manifest) needs to be updated with the new hash values of those signed files
Then the application manifest itself gets signed
The deployment manifest (.application) needs to be updated with the hash of the signed application manifest
Finally, the deployment manifest gets signed

Miss a step or do things out of order, and Windows will reject your deployment package. It's tedious and error prone to manage manually, which is exactly why we've automated it.

Certificate Requirements

ClickOnce and VSTO signing requires an RSA certificate with specific characteristics:

Algorithm: RSA only (ECC/ECDSA certificates are not supported by the ClickOnce/VSTO signing infrastructure)
Key size: Minimum 2048 bits, though 3072 bits is recommended for better security
Certificate type: Must be a code signing certificate (Authenticode) from a trusted Certificate Authority
Key storage: Since June 2023, CA/B Forum requirements mandate that private keys be stored on secure hardware (USB tokens or HSMs)

Signotaur supports all of these requirements, whether your certificates are stored on YubiKeys, SafeNet tokens, other PKCS#11 HSMs, or in the Windows Certificate Store.

The Publisher Name Challenge

Getting the manifests signed is only half the battle. Making your application display the proper publisher name instead of "Unknown Publisher" during installation is notoriously tricky. Even with a properly signed application, several factors can cause Windows to show "Unknown Publisher":

Certificate chain issues (missing intermediate certificates)
Publisher name in the deployment manifest not matching the certificate's Common Name exactly
Whitespace differences introduced during the signing process
Self-signed or test certificates (which will always show as unknown)
Certificate not from a trusted root CA

When everything is configured correctly, users see a clean installation prompt with your verified publisher information:

When something's wrong — even if the manifests are technically signed — users see the dreaded "Unknown Publisher" warning:

This is why using certificates from trusted CAs and ensuring proper manifest configuration is so important. Signotaur handles all the signing mechanics correctly so all you need to display the verified publisher name is a valid certificate from a publicly trusted Certificate Authority.

Signing Made Simple

To sign a ClickOnce or VSTO application, you only need to point Signotaur at the deployment manifest:

SignotaurTool.exe sign -a  -s  -t  --tr  --td SHA256 path\to\MyApp.application

Signotaur will parse the manifest, identify all the files that are part of the application, sign them in the correct order, and update the hash values throughout the manifest chain. Any files sitting in the deployment folder that aren't referenced in the manifest will be ignored, even if they match your file spec. This keeps things clean and ensures only application files get signed.

Command-Line Parameters

We've added a new --application-name parameter specifically for ClickOnce and VSTO deployments. This value appears in the Windows Start menu when users install your application, giving it a proper identity in the system.

The existing --description and --description-url parameters are used to populate the publisher name and support URL in the deployment manifest. This means if you're already using these parameters for other signing operations, your scripts should work with minimal changes.

What This Means for Your Build Process

If you've been juggling multiple tools or scripts to handle ClickOnce and VSTO signing, you can simplify your build pipeline. Signotaur handles the entire process as a single operation, maintaining the correct signing order and manifest updates automatically. This is particularly useful in CI/CD environments where you need reliable, repeatable signing without manual intervention.

The usual benefits of Signotaur apply here: your certificates stay securely on the server, private keys never travel over the network, and the command-line interface integrates cleanly with your existing build scripts.

For detailed command-line syntax and examples, check out the Signotaur documentation. If you run into any issues or have questions about signing ClickOnce or VSTO applications, our support team is here to help.

Using YAML with Delphi - VSoft.YAML

Tue, 16 Sep 2025 13:21:38 GMT

Introduction

Almost every modern Delphi application needs a way to store structured data: configuration settings, runtime options, or even project metadata. For decades, developers have relied on INI files for simple key/value storage, XML for deeply structured documents, or JSON as a lightweight alternative.

But there’s another option that has grown into the de facto standard in DevOps and configuration management: YAML.

This article introduces VSoft.YAML - an open-source Delphi library that makes working with YAML straightforward. We’ll cover why you might choose YAML over INI, XML, or JSON, then dive into practical Delphi code examples for parsing, editing, and writing YAML.

Why YAML?

Human-Readability

YAML is designed for humans first. Compare the following formats describing a database configuration:

YAML

database:
  host: localhost
  port: 5432
  user: admin
  password: secret

JSON

{
    "database": {
    "host": "localhost",
    "port": 5432,
    "user": "admin",
    "password": "secret"
    }
}

XML


    localhost
    5432
    admin
    secret

The YAML version is the least noisy, especially when configurations get larger.

Expressiveness

Supports mappings (key/value), sequences (lists), and scalars (strings, numbers, booleans).
Handles deeply nested structures naturally.
More flexible than INI files, which are limited to sections and key/value pairs.

Adoption

YAML is everywhere, especially in DevOps.

Introducing VSoft.YAML

VSoft.YAML is a pure Delphi implementation of a YAML 1.2 parser and emitter:

No external dependencies — just add the source to your project.
Round-trip capable — parse, modify, and write YAML without losing formatting.
Supports multiple documents in a single YAML stream.
Supports reading/writing JSON
Extensive JSONPath support

Getting Started

Installation

Clone the repo or add it as a Git submodule:

git clone https://github.com/VSoftTechnologies/VSoft.YAML.git

Then add the VSoft.YAML\Source folder to your Delphi project’s search path.

Parsing YAML

The most common scenario is loading YAML from a string or file.

uses
  VSoft.YAML;

var
  Doc: IYAMLDocument;
  YamlText: string;
begin
  YamlText :=
    'database:' + sLineBreak +
    ' host: localhost' + sLineBreak +
    ' port: 5432' + sLineBreak +
    ' user: admin' + sLineBreak +
    ' password: secret';

    Doc := TYAML.LoadFromString(YamlText);
    Writeln('Database host: ', Doc.Root.Values['database'].Values['host'].AsString);
    Writeln('Database port: ', Doc.Root.Values['database'].Values['port'].AsInteger);
end;

To load from a file, just call TYAML.LoadFromFile

Traversing Sequences

YAML supports lists (called sequences).

Example YAML

servers:
- name: web01
  ip: 10.0.0.1
- name: web02
  ip: 10.0.0.2

Delphi Code

var
    doc : IYAMLDocument;
    servers: IYAMLSequence;
    server : IYAMLMapping; 
    i: integer;
begin
    doc := TYAML.LoadFromFile('c:\test\config.yaml');
    servers := Doc.Root.Values['servers'].AsSequence;
    for i := 0 to servers.Count - 1 do
    begin
        server := Servers.Items[I].AsMapping;
        Writeln(Format('%s (%s)',[server.Values['name'].AsString, Server.Values['ip'].AsString]));
    end;
end;

Modifying YAML

Once parsed, you can update values and write them back out:

var
    root: IYAMLMapping;
begin
    root := Doc.Root.AsMapping;
    root.AddOrSetValue('environment', 'production');
    TYAML.WriteToFile(doc, 'c:\test\config.yaml')
end;

Practical Use Cases for Delphi Developers

Configuration files — ship your app with config.yaml instead of INI or XML.
DevOps integration — generate or consume YAML configs for devops tools.
Structured data — when you need nested lists or dictionaries without verbosity.
Collaboration — YAML files are easy for non-developers to read and edit.

Tips and Best Practices

Use JSON when machine-only consumption is expected.
Use YAML when humans will edit the config.

YAML Rules to be aware of

Even though YAML is designed to be human-friendly, it comes with its own quirks. Here are a few issues you might run into when using YAML with Delphi:

1. Indentation Rules

YAML is indentation-sensitive.
Spaces only — tabs are not allowed for indentation.
A single misplaced space can completely change the structure.

valid:
  key1: value
  key2: value

invalid:
  key1: value
   key1: value # wrong indentation

2. Duplicate Keys

Unlike JSON, YAML technically allows duplicate keys in mappings, but this can lead to unexpected behavior. YAML Parsers will typically keep only the last occurrence.

settings:
  timeout: 10
  timeout: 30 # overwrites the first one

VSoft.YAML has a parser option to control the handling of duplicate keys

options := TYAML.CreateParserOptions;
options.DuplicateKeyBehavior := TYAMLDuplicateKeyBehavior.dkError; // default is dkOverwrite
doc := TYAML.LoadFromFile(fileName, options);

Best practice: avoid duplicates in configs, and add validation in your app if needed.

3. Scalars and Quoting

YAML is permissive about quoting strings, which can sometimes surprise you:

path: C:\Temp\file.txt # might be misinterpreted due to backslashes

Safer to quote unusual strings:

path: "C:\Temp\file.txt"

4. Boolean Values

YAML recognizes a wide set of values as booleans: yes/no, true/false, on/off.

feature_enabled: yes # interpreted as boolean true

If you actually mean the literal string "yes", you must quote it:

feature_enabled: "yes"

5. Comments

While YAML supports # comments, they are not part of the data model and usually not preserved

VSoft.YAML does attempt to preserve comments. This is non standard. Generally, comments before mappings (objects) and sequences(arrays) are preserved, comments after scalar values may be preserved.

Blank lines will not be preserved.

6. Large or Complex Documents

For deeply nested structures, readability can drop.
Split configs into multiple YAML files if possible.
Use ---(start) and ...(end) to separate documents in a single file if needed.

7. Type Guessing

By default, YAML interprets unquoted values:

42 → integer
3.14 → float
3.1.4 → string
true → boolean

If you want to enforce string semantics, quote the value:

port: "5432"

8. CRLF vs LF Line Endings

VSoft.YAML is tolerant of Windows vs Unix line endings, but if your configs are shared across systems, normalize line endings in your source control to avoid “it works on my machine” issues.

Conclusion

YAML offers developers a unique combination of human readability, expressiveness, and versatility. Unlike INI files, it can represent complex nested structures; unlike XML, it remains clean and concise; and unlike JSON, it's easier for humans to read and maintain.

The full list of features support by VSoft.YAML is available here.

Signotaur and Certificate Revocation Lists

Wed, 09 Apr 2025 08:08:24 GMT

We recently had a report from a customer that code-signing using Signotaur was taking a long time — in this case, around a minute to sign one file. This is obviously far too slow for practical use.

The customer provided us with logs from two machines, which showed different results. When comparing the logs, the only thing that stood out was the Certificate Chain elements — the bad log only showed one element, whilst the good log showed three.

These chain elements make up the certificate path — each certificate is signed by another, and up the path we go until there are no more.

Seeing only one certificate in the path is a red flag. You would not typically see a code-signing certificate that is signed by a root certificate; there would be one or more intermediate certificates in the path.

Installing the Certificate Authority's intermediate certificates solved that part — the chain was complete. It did not solve the timing issue.

So we added more debug logging, and after much head scratching, we realised the issue was that the delay was due to the fact that, by default, when building the certificate chain, the .NET X509Chain class performs online checks of the Certificate Revocation Lists (CRLs).

Each certificate includes a CRL Distribution Points field that points to the CRLs. These CRLs are used to check if the certificate has been revoked.

Performing Online CRL checks (the default) can run into problems. In our customer's case, they were being blocked by their firewall — so each HTTP request timed out, resulting in signing taking longer than expected. Note it didn't fail the signing, since the CRLs were not retrieved. After the customer allowed those URLs in their firewall configuration, code signing was fast again.

If your internet connection is slow or has high latency to the CRL hosts, that will also impact code signing time.

The X509Chain class has two alternatives to online checks: Offline and NoCheck.

- Offline will use cached CRLs if available, and will not attempt to retrieve the CRLs online.
- NoCheck does what it says — skips the CRL/OCSP checks — and really should only be used in an emergency.

Signotaur v1.0.0.444 adds a new -rm option, which allows the values: Online (default), Offline, and NoCheck.

FinalBuilder 8.5 and Automise 5.5 Release

Wed, 09 Apr 2025 01:50:56 GMT

It's no secret that we are always working on the next version of FinalBuilder and Automise - that's the nature of software development. That said, the next major versions are taking much longer than we would like - the reason for this is dealing with serious technical debt (active scripting).

With this extended development cycle, there are changes that we finished some time ago that we decided just could not wait for the next major version. We backported those changes to the FinalBuilder 8.x and Automise 5.x - but since some of these changes break project compatibility (with the x.0 releases) we are releasing FinalBuilder 8.5 and Automise 5.5

Encryption Algorithm

FinalBuilder & Automise have always used the Blowfish algorithm (with a 160 bit key) for encrypting passwords, apikeys etc.

FinalBuilder 8.5/Automise 5.5 adds the AES 256 Algorithm (with a 256 bit key) as an option.

There is a new IDE option to specify the default project encryption for new projects - this defaults to AES256. Note this only affects New projects. To change the algorithm used for existing projects, open the project info window from the Project Menu, change the setting and click ok and then save the project.

Note that these options will be removed in FinalBuilder 9/Automise 6, when AES 256 will become the default (and projects still using Blowfish will be upgraded automatically).

It's should be noted that Blowfish is still considered reasonably secure, this change is to enabled the continued use of FinalBuilder in organisations must comply with NIST (US) or ASD (Australia) requirements.

Password Variables

In FinalBuilder & Automise we have always attempted to mask passwords from the logs, but occasionally that can slip through.

Any passwords stored in variables were visible in plain text in project project files. For this reason, we have added a new Password variable type. These variables will be encrypted in project files. The backing type is string.

Password UI

All password fields on all now utilise a new password edit control that allows peeking at the value (like the windows 11 password box).

Windows Credential Manager Actions

The Windows Credential Manager actions enable you to read/write/delete credentials stored in the credential manager.

Project file compatibility Warning

FinalBuilder 8.5 project files are NOT downward compatible with FinalBuilder 8.0 - or put another way, FinalBuilder 8.0 cannot load FinalBuilder 8.5 projects. The same applies to Automise 5.5 projects. This is due to some of the changes outlined above.

Code Signing with Inno Setup and Signotaur

Fri, 31 Jan 2025 01:04:38 GMT

Inno Setup has long supported code signing (since v5.2.4). Fortunately, the way the authors of Inno Setup implemented this feature makes it really easy to use custom tools to do the code signing. In this post we'll take a look at how to use Signotaur with Inno Setup.

There are a few different ways to specify which command to run during signing with Inno Setup.

Sign Tool settings in Inno Setup IDE

The first is to define "Sign Tool" commands in the Inno Setup IDE. You can create multiple commands - for example if you have multiple certificates - and then in your scripts you can point to the "Sign Tool" you want your setup script to use.

To define a "Sign Tool" command in the IDE - tools menu, Configure Sign Tools...

The name can be anything you want, however if you are including other third party inno scripts you should make sure the name is unique to make sure those scripts cannot redefine the command (this is pointed out in the docs)

Imagine if a third party script did this

[Setup]
SignTool=Default cmd /c format.com z: $f

If a Sign Tool named Default is defined in the inno IDE, that would be used. Of course you should always review any third party code before using it!

After providing a name, you are prompted for a command. This is where we can provide our Signotaur command line.

Inno Setup will replace a few placeholders

$f, replaced by the quoted file name of the file to be signed. (required)

$p, replaced by the Sign Tool parameters (more on this later).

$q, replaced by a quote, useful for defining a Sign Tool which contains quotes from the command line.

$$, replaced by a single $ character.

So with that, lets build our command line (adjust to suite your scenario).

e:\SignotaurClient\SignotaurTool.exe sign --sign-server https://mysignotaurhost:91/ --api-key *** --thumbprint YOURCERT-THUMBPRINT --fd "SHA256" --description "My Application" --tr http://timestamp.sectigo.com --td "SHA256" --allow-untrusted $f

Note - in Inno Setup 6.3.3 and earlier, the Sign Tool command line limit is 256 chars, which is a problem when using signotaur - this was fixed in 6.4.0. The work around for 6.3.3 or earlier is to modify the registry - under HKEY_CURRENT_USER\Software\Jordan Russell\Inno Setup\SignTools find the value for the Sign Tool you added and enter the full command line there.

Make sure to restart the Inno Setup IDE after making the registry change.

Now we can define which Sign Tool to use in our Innosetup project.

[Setup]
SignTool=signotaur

That's all we need for now - you should be able to see Signotaur being invoked to sign the uninstaller and the installer.

One downside to this configuration is that there is no way to parameterize the Sign Tool command, so no way to avoid hard coding the ApiKey in the command (which is stored insecurely in the registry). For that reason alone, I do not recommend configuring the Sign Tool this way.

Sign Tool settings in the setup project

So lets look at the second option, which is to fully define the SignTool command in the [Setup] section. IMPORTANT : Firstly, to keep the IDE happy, define your signtool as above, but with a command of

$p

then in your innotsetup project :

[Setup]
SignTool=signotaur e:\SignotaurClient\SignotaurTool.exe sign --sign-server https://mysignotaurhost:91/ --api-key **** --thumbprint YOURCERT-THUMBPRINT --fd "SHA256" --description "My Application" --tr http://timestamp.sectigo.com --td "SHA256" --allow-untrusted $f

Note that Signtool name in the project must be one that is defined in the IDE

That works fine, but of course now instead of hard coding the ApiKey in the registry, we have it in our project file - which is potentially worse since it's likely checked into version control (perhaps even in a public repo on GitHub!).

Sign Tool settings on the command line

To get around this, we need to change how we compile our Inno Setup projects. Using the Inno command line compiler lets us get around all of the issues.

To do this, remove the Sign Tool configurations from the IDE - we won't be using them.

In our project, we can use the pre-processor to only run the SignTool when Release is defined.

[Setup]
#ifdef Release
SignTool=signotaur SignotaurTool.exe sign --sign-server {#signotaurServer} --api-key {#apiKey} --thumbprint {#thumbprint} --fd "SHA256" --description {#MyAppName} --tr {#timeStampServer} --td "SHA256" -v --allow-untrusted $f
#endif

On the command line we can can provide values for the pre-processor defines

/DRelease /DapiKey=abcdef ...

That now moves the ApiKey to your build script.

There is one last option we can explore here - that is to provide the entire Sign Tool command on the command line for the iscc compiler

 
/Sname=command

Sets a SignTool with the specified name and command

e.g.

/Ssignotaur e:\SignotaurClient\SignotaurTool.exe sign --sign-server https://mysignotaurhost:91/ --api-key **** --thumbprint YOURCERT-THUMBPRINT --fd "SHA256" --description "My Application" --tr http://timestamp.sectigo.com --td "SHA256" --allow-untrusted $f

This is what the FinalBuilder InnoSetup action uses when you use the SignTool property. Of course you can use FinalBuilder variables for the ApiKey and other parts that might change. If you are calling FinalBuilder from a CI server, those variables can be provided from the CI tool - so the secret is stored and secured in one place.

One last comment before I wrap this up - why would I need Innosetup to handle Code Signing, can't I just sign the resulting setup.exe myself? The main reason for letting Innosetup handle code signing the installer is that it also signs the uninstaller.

Introducing Signotaur - Remote Code Signing Server

Wed, 04 Dec 2024 08:45:00 GMT

Over the last few years, code signing has changed somewhat. With the requirement that private keys be secured, many developers have run into the issues that USB tokens present, or the limitations and costs associated with cloud-based signing solutions. Gone are the days of sharing a PFX file around the dev team or with the CI server (unless you managed to snag a 3-year renewal just before the new requirements were enforced).

Signotaur

Signotaur is a self-hosted code signing server that makes sharing certificates simple, all whilst maintaining the security of your private keys. Signing can be done (using the client) from any machine that has network access to the server.

Secure Code Signing

Private keys never leave the server, or the USB token or HSM for that matter. The client/server both support TLS (and can generate a self-signed certificate during the install), and administrators can configure access controls to limit who can use certificates for signing. Signing uses API keys rather than passwords, so no more dreaded SafeNet or YubiKey password prompts!

Supported Certificates

We have tested with PFX files, SafeNet, Certum and YubiKey USB tokens, and Windows certificate stores. Signotaur may work with other USB tokens or HSMs that have 64-bit PKCS#11 drivers.

Lightweight

Signotaur Server uses very little memory, CPU, or disk space. It uses SQLite for its database. Installing Signotaur takes a few minutes at most.

Signotaur Client is a single native Windows executable (around 15MB). It's installed with the server and can be downloaded from the server's home page. The command-line interface is very similar to SignTool.

How does it work

In simple terms, the client calculates a digest of the files you want to sign, sends that to the server, which then uses the private key to create the signature and sends that back to the client. The client then writes the signatures to the files.

Supported Platforms

For this initial release, Signotaur (client and server) runs on 64-bit Windows 10+, Windows Server 2016, or later. Linux support for the server is in development.

Affordable

Unlike cloud-based services, we don't charge per signing, and the price isn't "available on application" like some "enterprise" products. The introductory price is USD $199 per server, and with the Black Friday Sale extended to midnight 8th December, that makes it USD $119.40 (discount applied at checkout). The price includes 12 months of updates and support. Renewals after 12 months are 30% of the new purchase price.

Download it here. After installation, login and browse to the admin\licenses page and request a 14 day trial license key.

Black Friday Sale 2024 - 40% off all new licenses

Thu, 28 Nov 2024 09:38:11 GMT

Black Friday Sale - 40% off all new licenses until midnight (utc) ~~4th December 2024.~~ Extended to midnight (utc) 8th December 2024.

No coupon code required, the store will apply the discount automatically.

FinalBuilder and Automise on Windows 11 24H2

Thu, 21 Nov 2024 22:35:00 GMT

The problem

Windows 11 24H2 breaks scripting in FinalBuilder and Automise. You will see a range of different errors depending on your scripts or the actions you use (some actions use jscript).

The cause

Windows 24h2 enables a policy by default that causes JScript.dll (the com dll) to load JScript9Legacy.dll rather than JScript9.dll

JScript9Legacy.dll is a replacement engine using Chakra - which is an odd choice since it seems abandoned since Edge moved to using chromium. The reason they did this was because of a security issue - which is understandable - but unfortnately it introduces a whole host of bugs they do not seem to interested in fixing (I guess it works for them).

This issue even affects some of Microsoft's own applications (like Visual Studio)

The work around

The workaround is to disable the policy

Run regedit.

navigate to (for all users) :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main

or (for the current user only)

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main

Note these keys did not exist on my machine, so I added them.

Right click the Main key and select New DWORD (32-bit) Value, name the new value JScriptReplacement and the value to 0.

Restart FinalBuilder (no need to reboot).

Obviously, this is not ideal - we have been looking to replace JScript for some time - unfortunately so far our efforts have not resulted in something that is 100% backwards compatible - so we still have some work to do in this area.

FinalBuilder 8.0.0.3378 and Automise 5.0.0.1593 breaking changes.

Tue, 16 Jul 2024 05:30:16 GMT

Throughout the lifespan of FinalBuilder and Automise, we have worked very hard to avoid breaking changes - however sometimes they are unavoidable.

Today's updates to FinalBuilder 8 and Automise 5 have a breaking change in the SSH Batch Execute action. Previously, this action would manage it's own connect/disconnect - the breaking change is this action now requires separate SSH Connect/Disconnect actions.

The reason for this is complicated, but it was brought about by us changing the client library we use for the SSH actions. The previous client library had too many issues that we were unable to work around. The most annoying example - the actions would not work correctly/reliably with openssh running on windows servers. We did try to fix this issue, but in the end the only viable option was to replace the library (something we were planning to do in the future anyway). The new library (Rebex) is much more stable and performant. We plan to re-implement the SFTP actions (which have issues with some servers) with this library in a future update.

We have been using a build with these changes in production for some time now to dogfood these changes.

To use the SSH Batch Execute action, add an SSH Connect action before it and an SSH Disconnect after, set the connection name on the SSH Batch Execute and SSH Disconnect to the name of the new SSH Connect action's connection name and you should be all set.

If you experience any issues with the SSH actions in these new updates let us know (with as much info as you can about the server and action settings).

Black Friday Sale 2023 - 50% off all new licenses

Fri, 24 Nov 2023 02:27:58 GMT

50% OFF. No, that’s not a typo! Our first ever Black Friday sale - 50% off all new licenses - valid to midnight Tues 28th Nov (UTC).

No coupon code required, the store will apply the discount automatically.

Code Signing with USB Tokens

Mon, 03 Oct 2022 16:40:22 GMT

Update Nov 2024

Whilst the content of this post is as valid today as it was originally, we became frustrated with being limited to signing on one machine. That meant our build agents were doing a lot of copying of files to and from the server with the token.

Our solution was to build a Code Signing Server - Signotaur - keep reading and then take a look at how Signotaur solves the problems we talk about in this post.

Big changes are coming for code signing certificates in 2023. New and reissued publicly trusted organisation validation (OV) and individual validation (IV) code signing certificates will have to be issued or stored on preconfigured secure hardware by the issuing Certificate Authority (CA) and the device must meet FIPS 140 Level 2, Common Criteria EAL 4+ or equivalent security standards.

This is already the case for EV (Extended Validation) certificates, and it presents some problems in an automated build environment. In this post we'll take a look at the issues with hardware-based certificates and how to work around them.

Why is this change necessary?

If you work in IT, you will have heard or read about the SolarWinds supply chain hack. It was a big deal. It's more common than we might think - in February 2022 NVIDIA had their code signing certificates stolen and they were used to sign malware (those certificates have since expired).

These (and other) episodes made many in the industry (Microsoft in particular) very nervous. Trust is a big deal when it comes to certificates, and that is certainly the case when it comes to certificate issuance, but there is not a lot of trust in how those certificates are secured by the developers using them. Ask anyone who has done the merry validation dance with a CA, it's not that easy to get a code signing certificate these days. With that in mind, the CA/Browser forum adopted a proposal to change the requirements for how issued certificates are stored.

The change makes a lot of sense - it's much harder to steal hardware than it is to steal files.

What does this mean

From 1 June 2023, all new and reissued publicly trusted OV and IV code signing certificates will have to be issued or stored on a pre-configured secure hardware device by the issuing certificate authority (CA) and the device must meet FIPS 140 Level 2, Common Criteria EAL 4+ or equivalent security standards.

Existing OV/IV certificates will continue to work, but if you need your certificate to be reissued you may encounter issues due to key size requirements changing (so don't lose your certificate). The reality is that most certificate providers have already switched to issuing certificates on tokens (or discontinued selling OV/IV certificates). This is the end of simply downloading a pfx.

What are these hardware devices

These devices fall broadly into 3 categories:

Network-attached Hardware Security Modules (HSM)

HSM's in this class bring a lot of benefits and functionality (like key usage audit logs) - code signing is just part of that. These devices are not cheap - usually in the "if you have to ask you probably can't afford" price range! There's a reason for that steep price though. They are designed to be ultra-secure and tamper proof - open the lid and you will likely lock it up or brick it.

CA's will charge you a premium if you BYOD (bring your own device) - expect an audit fee of around $500 - or you can employ your own suitably qualified auditor (no idea what the criteria is for that but it sounds expensive). You will also have to deal with creating a Certificate Signing Request (CSR) to send to the CA. The process varies depending on the device, and the CA websites don't offer much guidance there.

Cloud HSM's

Azure, AWS, Google and others provide cloud HSM's, a service layer in front of network-attached HSM's - you basically rent time/space on them. They typically charge a monthly fee and then a fee per cryptographic operation. CA's charge a hefty fee to create certificates for use on these services - up to $1200 - and on top of that some CA's charge per number of signings per year (no idea how they police that). You also need to do some work to configure secure access to the HSM. These services make sense if you are already running on the cloud. Like other HSM's you will need to create a CSR to send to the CA during the order/validation process

SSL.com offer an eSigner cloud-based service (they are also a CA), but the prices will make you think twice about code signing: USD $100 per month for 10 signings, plus $10 for each additional signing. We sign every build that might escape the building and each build has several files that need signing!

USB tokens

In my research so far, the most common USB token is the Gemalto/Thales SafeNet token. The only other ones I have encountered are Yubikey (only SSL.com seems to be using those) and Certum (for which I could find very little info on the client software). The token tends to be included in the price of the certificate (I did see one case where it was not). You do not need to create a CSR (unless you are using your own existing token) as the CA loads the certificate on the device before posting it to you. The one I have (from Digicert) is a Safenet token. It's already obsolete and cannot be used for new certificates as it doesn't support the larger key size required now (newer model required).

Locked In

One thing to note about all the possible hardware devices, whether it's yours or one you rent, is that once a certificate is installed on that device, it's private key cannot be exported. So if you decide the cloud service you are using is too expensive and want to move, well it's time for a new certificate.

Some CA's say they cannot reissue EV's on USB tokens, whilst others provide a procedure - it's likely you will be up for a new token cost and more verification hoops to jump through. So don't lose or damage it!

In the rest of this post, I'm only going to cover USB tokens. If you have access to network or cloud HSM's then you are probably well past this point.

So, what's the problem then?

Different USB tokens might use different client software/drivers - but they all have one thing in common - the USB token needs to be present (i.e. plugged in to the machine) when code signing. This seemingly innocuous little USB token (which looks just like a memory stick) needs to be physically secure. If someone walks past your machine and takes it (likely thinking it's a memory stick), well you are up a creek without a paddle. My SafeNet token has a bright blue LED on the end that just screams "Take me!". Our build servers are colocated at a data centre - so leaving things like USB devices plugged in is asking for trouble. It's not like I can walk over and plug it in when needed (every day!). The data center is 300km from where I live/work.

Add to this that build machines are typically virtual, so you are into the realm of USB passthrough. If you use Hyper-V Server (as we do), well you are bang out of luck.. not supported. I have heard that VMWare ESXI supports it just fine but have never used it. I tested with XCP-ng and did get it working, but it was a major hassle to configure (reams of commands and copying of guids).

USB - Remotely

Fortunately, there are alternatives to USB passthrough. I looked at a bunch of USB remoting products (USB over IP/UDP), and after poor results with most, I found one that works. In fact it works incredibly well, with much better pricing than the others.

That product is VirtualHere (VH). Of all the vendors I contacted, they were the only one who actually responded and answered the question I asked - "Does it support code signing tokens?". The author responded, "Actually I use my (Digicert) JC Token via VirtualHere to sign VirtualHere when I build VirtualHere inside a VM." Good enough for me to give it a try!

The VH Server runs on Windows, Linux, MacOS, a bunch of NAS servers, even a Raspberry Pi! The server licence is locked to the host machine, so if you decide to move the USB token to another host you will need to purchase another license - but at USD$49 that probably won't break the bank!

I installed the VH server software on my XCP-ng host - installation was trivial and took all of 2 minutes (I'm no Linux expert). I then plugged the USB token in (the server is in my mini rack at home) and installed the VirtualHere client software on my Windows machine.

The VH client can auto detect servers, however in my case the two machines were on different subnets, so I had to manually specify it. With the trial version, a message box shows up when it first connects. The client immediately showed a tree of the USB devices plugged into the server. The SafeNet token shows up as Token JC, right-click on it and select "Auto use this device" so it connects automatically. When I did this, the familiar Windows sound indicated a device had plugged in. I already had the SafeNet software installed so it didn't prompt me for drivers etc.

The last step in this USB remoting journey was to install the client as a service (right click on the USB Hubs node). This can only connect to licensed servers, so leave this step until you have purchased.

NOTE : I didn't make it clear before, but the VH client and token client software need to be installed on the machine where the signing takes place, ie your build machine or build agent machine.

Prompting for Passwords

Another issue with the USB tokens being present during code signing, is they also expect a human to be present - a password prompt is shown. That flies in the face of conventional wisdom - automate all the things!

Fortunately, for the SafeNet token at least, there is a work around for this.

Open the Safenet Authentication Client Tools, click on the Advanced View button (the gear). You may be prompted for the token password if you haven't already entered it. In the tree on the left, right-click on the certificate (under User certificates) and select Export certificate. Just to be clear here, this is the certificate without the private key (which stays on the token) - you can't use this exported certificate on a machine that does not have access to the USB token.

In the certificate view, under Private Key, take note of the Cryptographic Provider value (likely "eToken Base Cryptographic Provider" and the Container Name (p11#xxxxxxxxxxx). You will have to manually type them out somewhere as it doesn't support the clipboard. Save those values somewhere - as you will need them in your build process for code signing.

Whilst still in the Client tools, select Client Settings and go to the Advance tab, check the "Enable single Login" and "Enable single Logon for PKCS#11." options, and set Automatic Logoff to Never - then hit Save. You can close the client now.

Code Signing

With all that done, we can use Signtool action in FinalBuilder. The Signing option tab is where those values we saved earlier come into play.

The only difficult one is the Private Key container. Fortunately, some clever person on StackOverflow figure out the required format:

[{{%CSPWD%}}]=p11#xxxxxxxxxx

I have used a variable CSPWD for the token password.

That's it. In my tests I have run FinalBuilder from the Windows task scheduler while logged out, and from a Continua CI build agent service (again while logged out) and it worked in both instances. I did a bunch of login/out/reboot testing and it continued to work. VirtualHere has been flawless. The next step is to configure our CI agents to access the USB token over VPN. Sadly our EV token is about to expire (and we never used it once in production, our OV cert still has another year left) - so I first have to jump through the validation hoops to get a new one.

When using this technique on a CI server, you will need to take care that only one build at a time is using the token. In Continua CI, that is trivial to achieve using a shared resource lock.

I would love to test out some of the cloud HSM services too, but purchasing a certificate for each one is too rich for me. If you are using any of those with a cloud-based HSM, jump on our forums and let us know your experiences. If you experiment with or get up and running using VH let us know how it went - I might do a follow up post as we all gain more experience with usb tokens and code signing.

Warning (added 19 Oct 2022)

I probably should have pointed out that most tokens are configured to lock you out after too many authentication failures. So if you are getting auth failures when setting this up, stop, and manually login to the token to reset the failed count.

Rant

CA's (and their resellers) have some of the worst websites I have ever had the displeasure of reading. Pages and pages of useless or contradictory information with links promising more information that take you around in circles. Grrrrr.

Continua CI System Server Properties

Thu, 13 May 2021 12:59:28 GMT

If you are using Continua for your CI, (and if not why not?) ensure that you check out System Server Properties. These allow access to global settings which do not fit on any existing page.

They can be used to configure several aspects of the UI and build process to fit your team preferences. This could simply be the number items to show per page on each of the dashboard views (Server.ProjectsView.*.PageSize), or more complex patterns for detecting errors and warnings in actions settings (Actions.Messages.*Patterns). Some system server properties are rarely needed, but some can be considered essential, such as Server.HostUrl which can be used to ensure the links in notifications go to the correct external host name.

We have recently added some new server properties which allow you to control the tabs on the Queue Options dialog (Server.QueueOptionsDialog.*) and create a banner for displaying a message to all (or a subset of) users (Server.Banner.*).

Here is the result of changing Server.QueueOptionsDialog.TabSequence from "Variables,Repositories,Options"

to "Repositories,Variables,Options".

This is what happens to an existing banner when you change the Server.Banner.MessageType from "Information"

to "Warning".

Server properties can be edited on the "Continua Server - Properties" page located in the "Administration" section of Continua CI. See our documentation for details on all the currently available server properties.

DPM Package Manager - Progress update

Wed, 24 Feb 2021 10:46:15 GMT

In December 2019, I blogged about a package manager for Delphi that I am working on. This post is a progress update that shows where it's at and what's left to do to get to v1.

DPM Recap

For those not familiar with what I am trying to achieve here, I highly recommend reading my original Delphi Package Manager RFC post. In that post I detailed my ideas, and some of the challenges that Delphi presents when compared to other development environments.

In December 2019, the bare bones of DPM were there. We had a command line tool and that was it. We were able to create packages, install packages (and their dependencies) and restore them (restore ensures all referenced packages are present). Oh and we could list the available packages in our package feed (a folder).

IDE Integration

In the last 13 months there were around 175 commits to the DPM repository. In that time I have added an IDE plugin (that works in Delphi XE2 to 10.4). This involved the creation of several custom controls (I wasn't able to bend any existing ones to work how I wanted it to).

In addition to the work in the project repository, I also published several useful libraries that I needed for this project. DPM is now bootstrapped, to build DPM you need DPM, as it requires several libraries that are referenced as dpm packages.

In Nov 2020 I published the first alpha release that included an installer (code signed by VSoft Technologies) for installing both the command line tool and the IDE plugin (single installer, you can choose which IDE versions to install for). The installer allows you to install for the current user, or for all users (requires elevation to install).

I also did a zoom presentation about DPM to the Melbourne chapter of the Australian Delphi Users Group - a recording of that (long) presentation can be found here.

Adding IDE support for DPM was a massive undertaking. I had very little experience in developing Delphi IDE plugins (using the tools api) - and there were lots of subtle changes between delphi versions, getting things working correctly in 12 versions of Delphi was not easy. In particular, with the later versions of Delphi IDE that use VCL themes, getting things to look right (ie like a native part of the IDE) was a challenge.

The above image shows the installed packages for one of the projects in the project group, you get to this view by right clicking on the project node, or the DPM Packages node in the Project tree.

Note the view only shows the directly installed packages, not the transient dependencies - those you can see in the project tree under the DPM Packages node.

Before you can use DPM in the IDE, you need to configure a package source (a folder where your package files will live)

This can be done fron the command line

dpm sources add -name=local -source=path to the folder you created

Or from the IDE Settings

Compile during install

The most recent updates added support for compiling packages during first install. Packages need to declare how to build in their dspec file, and dpm will use that and call msbuild to compile the packages if needed. DPM also records a bill of materials file (package.bom) in the package cache so that it can tell whether the package needs to be recompiled or not.

On first install, packages that are being compiled during the install process will take a little longer, but on subsequent installs or restores, the process is almost instant (a few ms).

Prior to adding this feature, building dpm on our Continua CI build agents took 13 minutes, much of which was taken up with compiling the dpm packages that it references (in particular, earlier versions of Delphi were very slow with spring4d). Since updating dpm on our agents with the new version, the entire build process for DPM (console app and 12 versions of the IDE plugin and the installer) takes less than 2 minutes.

Missing features

Project group support

When installing packages, the dependency resolution code does not know about other projects in the project group, or what packages and versions they reference. This will be a problem for packages that include design time components that need to be loaded - the IDE can only load 1 version of a design time package. This is what I am currently working on.

Design time packages

DPM does not currently install design time packages into the IDE. This is dependent on project group support, so it's next on the list after project group support.

Package Updates

The ability to detect when package updates are available and make it easy to install those updates. There's an Updates tab in the IDE but it's non functional at this time.

Package Repository

In it's current state, DPM only supports folder based package feeds. This works fine, but it does have some limitations

Limted search abilities - limted to searching on the package filenames.
You have to download packages to a folder.
Package Authors have to host the package files somewhere (mine are under releases on their github projects).

I have made a start on the Package Repository, but not a lot of progress since I'm focusing on the client site right now.

Q & A

Is it usable?

In it's current state, it's only usable for non visual libraries. As I mentioned, the DPM projects all use DPM themselves, and we have DPM actions in FinalBuilder for running the Pack and Restore commands.

If you use any of my open source libraries like DUnitX, Delphi Mocks etc, I have created packages for all of those libraries, and also created mirror projects (just for hosting the package files) for some other popular libraries like Spring4D.

I would encourage library authors in particular to take a look and provide feedback.

Where can we find it?

DPM is an open source project on GitHub, the installer can be found under Releases (under each release, there is an Assets dropdown section).

What versions of Delphi does it support?

Delphi XE2 to 10.4.2 - note that we compile with the latest updates installed for each compiler version.

Why is it taking so long?

Yes, someone asked that recently! This is a side project, free and open source. My primary focus is on running my business and working on our products (that keeps the lights on).

Can we sponsor the project?

Not right now, however it's something I'll look at in the future.

Can we help?

Absolutely. Fork the project on GitHub and clone it to your dev machine and spend some time getting to know the source code. Before making any pull requests, create an issue on github to discuss your ideas and make sure we on the same wavelength!

Advice for Delphi library authors

Wed, 24 Feb 2021 00:57:00 GMT

We use many third-party Delphi libraries to build FinalBuilder and Automise, and that brings plenty of issues when upgrading compiler versions. I've been using Delphi since 1995, both as a developer and as a component vendor, I have learned a thing or two about creating libraries that I would like to share. These are all ideas that make life easier for users, and make it easy to migrate from one version of Delphi to another.

There's no hard and fast rules on how Delphi Libraries are supposed to be structured, these are just my preferences and things I have learned over the years. Hopefully this will help new and existing library authors.

Folder Structure

Keep the Source and the Packages in separate folders, this makes it easier to find the correct packages to compile, e.g :

\Source
\Packages
\Demos

Under Packages, create a folder for each compiler version your library supports, e.g:

\Packages\Rad Studio XE8
\Packages\Rad Studio 10.0
\Packages\Rad Studio 10.1

Package Names

Please, do not put the Delphi version in the package project names.

Bad!!!

MyProjectRun_D10_4.dproj
MyProjectDesign270.dproj

Good

MyProjectRun.dproj
MyProjectR.dproj
MyProjectDesign.dproj
MyProjectD.dproj

Why not put the compiler version in the package project name you might ask? Well the answer is that it makes upgrading compiler versions a major pain for users who link their projects with Runtime Packages (yes, that includes us).

The reason is that when you compile a package, it creates a packagename.dcp file and that is what your project references. So, if your package name is MyPackageRun_D10_4 then that is what will be added to projects that use it.

package MyOwnPackage;
//...
requires
  rtl,
  vcl,
  MyPackageRun_D10_4,
  AnotherPackage_Sydney,
  YetAnotherPackage_D104,
//  ...

When Delphi 10.5 comes out, guess what the user has to do to upgrade their projects.... Yep, replace that all those package references with 10.5 versions (and the multitude of suffixes). Multiply that by a number of projects and a number of libraries (each with potentially multiple runtime packages) and you can see why this might be a pain.

Now you might say, but we don't want 15 versions of MyPackageRun.bpl laying about on users machines, and you would be right. The solution to this is a feature that has been around since Delphi 6 (2001) - LIBSUFFIX.

Setting LIBSUFFIX (on the Description section of project settings) will append the specified suffix to the BPL file name. So a suffix of _D10_4 will result in a package :

MyPackageRun_D10_4.bpl

however, the DCP file will still be generated as :

MyPackageRun.dcp

Remember it's the dcp file that our projects reference (for linking) - so by keeping the dcp file the same for all delphi versions, upgrading to a new compiler version just got a whole lot easier!

So when Delphi 10.5 comes out in the future, all I need to do is install the packages, no changes to my projects.

Update : Someone pointed out that Delphi 10.4.1 support LIBSUFFIX $(Auto) - this will use the Delphi defined PackageVersion - which for 10.4 is 270. This is a nice addition as it makes upgrading the package projects simpler. Of course if you don't like the PackageVersion suffix and use a custom one, then this is not for you.

Use Explicit rebuild, not Rebuild as needed

Have you ever encountered the error

E2466 Never-build package 'XXX' requires always-build package 'YYY'

What this means is, a package, set to Expicit rebuild, references another package, set to 'Rebuild as needed', and it's a pain in the proverbial. Rebuild as needed is also referred to as Implicit Build - in dpk's you will see it as

{$IMPLICITBUILD ON}

If that "Rebuild as needed" package is not part of your project group, guess what, you get to waste time closing and opening projects trying to get it to compile.

I'm sure someone will correct me on this, but I cannot see a good reason to have "Rebuild as needed" set. I suspect this is a hangover from before the Delphi IDE allowed you to specify Project Dependencies and it slows down builds.

Use Search Paths for includes

I often see includes with either hard coded paths, or relative paths like this :

{$I '..\..\MyDefines.inc'}

That's great, if the installer delivers the files in the right place - but they often don't - I hit this issue today, where the package just would not compile. I eventually figured out that the relative path was wrong.

There's a simple fix for this, and that is to remove the path in the $I statement, and use the Project Search Paths feature instead.

I have also seen libraries where there are mulitple copies of the include file and they are slightly different!

Mark packages as Runtime only or Designtime only

Some libraries have their packages marked as "Runtime and Designtime" (the default) - the impact of this is only minor, but it's a pet peeve of mine. The Delphi IDE (in recent versions at least) provides a nice indication of whether packages are runtime or designtime in the project tree, and for designtime packages, whether they are installed.

This makes it simple for me to determine which ones need to be installed or not.

Not Installed

Installed

Summing up

One of the major reasons people do not upgrade Delphi versions is because it's too hard to deal with the third party libraries and all the changes required just to get to the point of compiling. That eventually results in a lack of Delphi sales which results in a lack of investment in Delphi which feeds back into.... well you get the idea ;)

Making third party libraries easier to work with in Delphi has been a bit of a crusade for me, I've been working on this for a while now, and I'm getting closer to a solution - DPM - A package manager for Delphi - if you are a library author, I encourage you to take a look. For examples on how to create a package spec (dspec) take a look at our open source projects https://github.com/vsoftTechnologies/

Announcing the Release of Continua CI Version 1.9.2

Mon, 09 Nov 2020 06:16:32 GMT

We are delighted to announce that version 1.9.2 of Continua CI has passed through the beta and release candidate stages, and has now been released. Here is a reminder of the new features in v1.9.2:

Export and Import: You can now export one or more configurations to a file and import them back from the file into Continua CI.
Requeuing Stages: Requeue a failing stage without restarting the build.
Multiple Daily Cleanup Rules: Each type of build by-product can now have a different shelf life.

Export and Import

Users with Configuration Edit permissions can now export one or more project configurations to a YAML or JSON file. This may be for backup, versioning or migration to another server.

The export wizard has a number of steps allowing selection of one or more configurations, and also any related repositories, variables and shared resources.

The configuration details can be exported to YAML or JSON file formats, according to your preferences for readability and differencing.

The resultant file is downloaded to your computer, allowing you to file it away until you need it.

The import wizard also consists of several steps, allowing users with Project Edit permissions to upload a file, ...

choose which items in the file to import and whether to overwrite any existing matching items of create new items.

The import runs in a transaction, so if any modified file content fails validation it will rollback...

allowing you to make changes and retry.

Requeuing Stages

Sometimes a build stage may fail due to external influences. It could be that a file server was offline, network connectivity was down, or a file was locked for access. If it has taken several long stages to get to this point, then having to run the whole build again from the start can be a pain.

The last stage of a completed build can now be requeued, providing that it has failed, stopped or errored, and the server workspace is intact.

If no parts of the server workspace have been removed by the cleanup process, then a Requeue Stage button will be shown after the last stage in the Stages list on the Build page.

This allows you to requeue and execute the stage again!

You can also optionally make changes to the stage actions and requeue the stage with the latest changes.

Multiple Daily Cleanup Rules

Every build that is executed within Continua CI stores information in the server's workspace, such as artifacts and build logs, and entries in the database. These by-products are vital for executing your build process and tracking build information, however, they can also take up considerable disk space over time and have a negative impact on database performance. The cleanup settings define the shelf life for the build by-products.

Up until now, the cleanup settings have been quite limited - you could set up a single policy per configuration defining the build age and build limits for cleaning up either the database, the workspace, or both. Often, however you would want to cleanup the workspace files to save space, well before removing the build from the database. This update allows you to define multiple cleanup rules, with different shelf lives for each type of build by-product.

Each rule can include one or more by-product to clean up.

Download the installers for Continua CI v1.9.2 from the Downloads page