Package: ftp.debian.org Severity: normal User: de...@kali.org Usertags: origin-kali
I first wanted to report that it's too easy to introduce conflicting files with the same name in the case of upstream signatures (*.asc files uploaded with the original tarballs) because it's really easy to drop them in a subsequent upload, get them forgotten by dak and reintroduce a conflicting file later one. Consider dbus-glib: https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a different .asc file And I wanted to suggest to not forget files for as long as the corresponding source package is still there... But after further thoughts, it appears to me that it's not a good idea to store such files in that way... those files are not really meant to be immutable: - signing keys can expire and be revoked, upstream might want to update signatures of already released tarballs - the set of "upstream release managers" might evolve over time and the official signature to use might change... If we assume that the archive is meant to store immutable content under a given filename (and to me that requirement seems to be a good idea), then we should question ourselves whether we really want to store those signatures in that way. They should either be tied to the Debian revision (so that they can change over time without any new upstream release) or be incorporated in the Debian tarball. Cheers, Raphaël.
