@atripp

Ah, thanks, I did not read
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds
well enough, my bad, sorry.

I'll talk to DevOps about the update then. Thanks for the fast reply!

Best,
Frank

Hey team,

just stumbled accross the signing v3 problem with my feed and wanted to make it work again.
Re-uploading packages did not help, so I deleted all from the feed and also wanted to replace the signing key. After clicking on "Delete key" the button went grey and nothing further happened, so after some coffee I closed the window. Reopening it again showed the key had been deleted anyways, so I clicked "Generate new key", which quite like before did go the way by the button going grey and nothing further happening. I closed the window again this time after a few seconds and a new key seem the have been created.
I reuploaded all packages again, but sadly the error about the rejected message is still there.

Do I need to delete the whole feed?

How do I check within proget about the used signature?

We are using ProGet Version 2025.12 (Build 20).

Many thanks,
Frank

Hey Steve,

thank you very much. That sounds like a valid explanation. Let me try to work this out with the third party then and see if I can get them to look into their build process.

I thought about repackaging and looked into the ar parts too, but since this then needs to be done for every version coming out, I would rather not be an additional step in between and have it working out of the box. ;)

Many thanks,
Frank

Hey team,

I'm having issues uploading a specific Debian package to ProGet:

Although the package is quite simple and contains a control file, proget says it does not.

└── pkg
├── DEBIAN
│   ├── control
│   └── md5sums
└── usr
├── bin
│   └── connecTI-Key
└── share
├── applications
│   └── connecTI-Key.desktop
└── icons
└── hicolor
├── 128x128
│   └── apps
│   └── connecTI-Key.png
├── 256x256@2
│   └── apps
│   └── connecTI-Key.png
└── 32x32
└── apps
└── connecTI-Key.png

Manual installation per apt works fine.

Unpacking it with dpkg-deb -R and repacking dpkg-deb -b seems to fix it?
I afterwards was able to upload it. It is a third party package, how can I find out why the originally provided version is not accepted?

Many thanks,
Frank

Hi Alana,

thanks, great to hear you are working on this and it is also being an improvement. :)

Waiting for the update then and wishing a good start into the week,
Frank

Hey team,

hope you are well!

With Debian 13 Trixie, I do get this error with our proget repo:

Warnung: https://proget.<reponame>/debian/<feedname>/dists/trixie/InRelease: Policy will reject signature within a year, see --audit for details
Audit: https://proget.zollsoft.de/debian/deb-proxmox/dists/bookworm/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
Error: Policy rejected packet type
Caused by:
Signature Packet v3 is not considered secure since 2026-02-01T00:00:00Z

I've read some git and reddit threads about the issue, but marking the repo as trusted and allow_insecure doesn't solve the issue for me really. At https://tracker.debian.org/pkg/apt I might have missed information about it. So checking in with you guys, if you are aware of this.

Many thanks,
Frank

Hey Alana,

thank you very much. Maybe this is some issue with our setup then. I will further check and investigate on our side first. :)

Best,
Frank

Hey Team,

when developing and testing Debian packages, I sometimes do not increase the version of the package for testing as this sometimes unneccessarily makes version increments higher than needed.

Our internal repo is replicated to an external repo from which most machines download their packages.

I stumbled accross the issue, that the package is uploaded by me to the internal repo, but it is not getting replicated to the external one, if I do not increase the version.

Can the replication be extended to check for a different timestamp / hash value, so packages will be replicated even if their version is the same, but the timestamp is newer, the hash value has changed?

Many thanks!
Frank

Hey Alana,

sorry for the late response!

And thank you for the update. You are totally right, this will not happen often, even rare, so I think we can work with this solution. :)

Have a great day,
Frank

Hey Alana,

thank you for the reply.

Our security team is asking to be able to revoke public keys and swap them out as a preventive action or in case of bad things that might happen.

While you are right, that SSL/HTTPS does secure the connection to a server, I haven't heard of signing repos is deprecated.

It ensures (besides the SSL/HTTPS) that the packages downloaded are eligible and verified for installation from the configured repo.

If this is not supported, then that's the way it is, although being able to upload a custom signing key would be a great feature. ;)

Have a great day,
Frank