Inedo
ProGet 2025.14: Major Updates to Debian Feeds
Although ProGet 2025.14 is a maintenance release, it has three major changes to Debian feeds.
We would normally wait until ProGet 2026 for this kind of update, but we’re racing against the clock. There are some upcoming changes in Debian 13 (Trixie) that will not be compatible with ProGet.
This blog post serves as a combination of release notes and technical background on these changes. Overall, the changes are lot less riskier than they sound, and if you have any issues upgrading, you can simply rollback.
🔐Library Change: Signing Key Changes (PG-3110)
A few months ago, Debian 13 started issuing warnings to ProGet users:
Warning: https://proget.server.corp/debian/cloud/dists/trixie/InRelease: Policy will reject signature within a yearWhat this message means is that, starting in February 2026, apt in Debian will begin rejecting the older-format signatures (i.e. PGP v3 format with an SHA1 digest) issued by ProGet 2025.13 and earlier.
Signatures issued from ProGet 2025.14 will work fine and do not generate this warning.
Background: v3 PGP Packets
PGP’s v4 packets have been around since 1994. That’s over 31 years ago from when this post was written – so why in the world is ProGet using it? To be honest, it’s just a bug. Due to a quirk of the PGP library we were using (Bouncycastle), this was enabled by default, and apt has happily accepted it up until now.
Unfortunately, fixing the issue was a lot more involved than simply changing a default. The library simply would not produce anything except a SHA1 content digest, which meant that Debian would still reject it.
To give us full control over the signing process, we decided to solve the problem ourselves with a new, internal library called LilPgp.
Developing & Integrating LilPgp
Upgrading a library in a maintenance release can be a little risky, while switching one out completely can be really risky. But we didn’t have much of a choice and, fortunately, this change only impacts Debian feeds. However, as the “lil” prefix implies, our LilPgp library doesn’t implement the full suite of tools that gpg can perform. It only does public/private RSA key creation, signing, and PGP packet processing.
Though non-trivial, it proved to be an easily surmountable task that greatly improves our Debian experience and lays the foundation for adding repository signing to other ecosystems that use PGP (such as RPM). We now have a solution for any PGP operation we need and in addition to producing PGP packets exactly as we need them, it’s fully capable of automated testing.
💼New Feature: Bring Your Own Key (PG-3110)
While addressing the upcoming PGP incompatibilities, we also decided to improve the usability of Debian feed key management. Like before, creating a Debian feed will automatically create a secret key, and you can delete or create a new key within ProGet any time.
However, in ProGet 2025.14, you will be able to upload your own secret key from the same key management page.
Additionally, we now support keys with an expiration date and will generate Release/InRelease signatures that respect this value, and you can extend or change a key’s expiration right from ProGet if you need to.
🛜 New Feature: Index Jobs for Debian Connectors (PG-3135)
In ProGet 2025.14, we added an improved way to connect to large, public Debian repositories.
Background: Query vs Catalog APIs
ProGet is designed around a queriable package metadata index (i.e. a database). When packages are added to ProGet, their metadata is immediately indexed, which means API calls to feeds will always return the latest metadata. While this query-based approach works great for NuGet, npm, and many other package types, it’s much less optimal for the “catalog”-type APIs that Debian uses.
In contrast to an API where a client can request information about a package or conduct a search, this is the kind where the client is expected to periodically download a complete index of packages and perform that indexing itself. Of course there’s nothing wrong with this approach, but it’s at odds with ProGet’s model and has historically caused a number of scaling issues when dealing with connectors to very large repositories that change frequently.
To try to square this circle, we adopted a kind of hybrid model for this type of repository where the remote data would get reindexed when it changed, and ProGet would generate and cache its own indexes for clients as either its own data changes or a change from a connector was detected.
This works well for small to medium sized repositories and has the benefit of exposing instant updates to consumers. Unfortunately it scales very poorly to large repositories.
Introducing Indexing Jobs
To solve this problem, we’ve added job-based indexing to feeds with this model, starting with Debian since it has been most affected by this to date.
As we are including this in what we’d normally consider a maintenance release, it will be an opt-in feature, and we currently recommend it for large feeds or feeds that mirror one of the large repositories used by your typical Linux distro (Debian trixie, Ubuntu jammy, etc).
As we move toward ProGet 2026, we will likely be adding this capability to other similar package types (rpm, apk, conda), and will likely make it the default indexing mode for them in ProGet 2026.
How to enable the indexing job for Debian
To enable background index generation for a Debian connector, go to the connector’s settings page and find the new “Index poll frequency” text box. Set it to the number of minutes to poll the remote repository for changes in the background. When this value is not set, ProGet will update indexes on-demand as in previous versions.
To enable background feed index generation for a Debian feed (essentially this is the feed’s Release file), go to the Manage Feed page for your Debian feed. Find the new Index File Generation setting and check the box labeled “Generate index files in background”.
