Re: dpkg-sig support wanted?
Anthony Towns <firstname.lastname@example.org> writes:
> On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
>> Anthony Towns <email@example.com> writes:
>> > On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
>> >> Use 1: I have this deb in my apt-move mirror and I want to know if it
>> >> was compromised on yesterdays breakin
>> >> Boot a clean system with debian keyring and check all deb
>> >> signatures.
>> > Find some don't pass because they were signed with keys that have been
>> > removed from the keyring.
>> Those I remove and refetch from a clean source again. False negatives
>> are no big deal. 99% of the debs will verify leaving only a
>> managable amount of wokr behind.
> The "clean" source that's signed by the same key that you can't verify?
If I can't find any verifiable source then the package can't be
trusted and can be removed till that is changed. Still much better
than having 100% untrustworthy packages.
>> Ah, I see the light.
>> Signatures are useless because packages have no signatures.
> That's a transitional problem, yes. In this case it's a severe one;
> since there are up to 150GBs worth of .debs. It's a problem that could be
> solved if it were worthwhile, but it's not worthwhile since .changes
> already do everything deb sigs could do without any transition issues,
> and it's not something that can be simply ignored.
By the way, this is trivial to work around:
1) archive the Release.gpg, Release and Packages file from today
2) only allow signed debs from now on
>From then on all debs can be verified.
I say the transition can be simply ignored (for now). The problem will
fix itself in due time when signed debs become more popular and
debsign automatically adds them. At some point in the future the
majority of debs will be signed and then a transition can be force by
scheduling a binNMU for any remaining deb.
But first there must be an official "debs may be signed" before anyone
can think about a "debs MUST be signed".