leaks in our only-signed-software fortress

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
Hey.

I've decided that I think it's important to CC this d-d:
Debian has a good system of securing packages and making sure that only
signed stuff comes to the user.
Over time I've seen many holes in this:
- packages that are just wrapper packages, download something from
somewhere without doing any
   hashsum checks at all
   Some firmware packages, some font packages, documentation etc. is/was
like that.
- packages that eventually run some code which was downloaded
unsecured.
   debootstrap used to be like that, pbuilder, and some others
- Some packages load and process content that could be secured but
(is/was) not.
   IIRC the Contents Files are not signed and therefore e.g. apt-file
cannot secure this.
Of those who actually DID checks, there were several that used weak
checks (even though there was no
need to),... e.g. things like MD5 checks instead of something "better".

For many of those I've reported bugs (and I'm sure I didn't found a lot
of them, and I'm further sure
that new cases were introduced).
Some where closed, some where just ignored or denied.


Recently with the Web2.0 and AppStore/Marked/etc. hype, things got even
worse.
I've you wanna be cool, you cannot just distribute software that people
can get and install regularly.
You need some AppStore, where no user has any controll on
sources/security/etc. often you even cannot
control when updates happen.

Mainly via the browsers (Mozilla, Chromium) this shit has found it's
way into Debian.
Software installation bypasses the Debian archives but comes directly
from any internet source
and get's installed locally in the user's homedir.

For Firefox we have fortunately a good team, which does real packagin
of the extensions and the plugins.
And Mike and the FF maintainers do a good job in trying to integrate
Mozilla's extension crap into the
Debian way.
Nevertheless there are still holes from time to time,.. e.g. that FF
tried to update extensions installed
from a Debian package.


Now the GNOME guys (talking about upstream) seem to be the new kids at
the sandbox and when the've decided
to assimilate the world with GNOME shell they also needed kind of an
app store, I guess.
See my bug #660311.

Personally I decided to use GNOME-fallback, but via the meta-packages I
still got the GNOME shell... today
I've noticed that it silently installs an extension, which (I can only
assume this by the little
description) does some software installation/enabling for GNOME shell
from extensions.gnome.org.
To me this sounds more like a root-kit than a feature.

This rant is not (!!) about blaming our GNOME maintainers, who really
do some good job, ... I just hope to start
some discussion about how Debian should deal with such hype
developments ("Apps") which may be nice
for users, but not for security.
And also about the other mentioned "holes" in our beloved fortress that
allows only signed code
to get onto the system (unless of course you install something manually
:P)

I mean there would be many places in Debian, where security could be
improved... webservers shouldn't need a
fancy default-works-out-of-the-box config which displays some Hello
World pages... and actually, IMHO installing
a daemon should not mean that it's automatically enabled (speaking of
init scripts)... the config is likely
not yet finished/secured.
Well I doubt that things will change there... but we really should take
care on whom we allow to provide our
users with "external" software. Especially when this happens easily
without the control (or much interaction)
of the users and/or admin.


Cheers,
Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/0763775752c72b696283491568e04907@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Teus Benschop-2
To put things in perspective, I just wonder how strong this 'fortress'
really is, and whether this strength is only in our perception or
whether it is real. Let me give just one example: A developer downloads
a tarball from an upstream source, configures it, and does make install,
yet has not even once checked whether this tarball is secure or is not a
root kit. Teus.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F3F5D25.3000502@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Thomas Koch-11
In reply to this post by Christoph Anton Mitterer-2
Christoph Anton Mitterer:
> Hey.
>
> I've decided that I think it's important to CC this d-d:
> Debian has a good system of securing packages and making sure that only
> signed stuff comes to the user.
> Over time I've seen many holes in this:
> - packages that are just wrapper packages, download something from
> somewhere without doing any
>    hashsum checks at all

I'm as concerned as you are and collected some examples over time that might
give a perspective:
http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html

    September 2009 Apache.org got hacked - twice in eight months.
    December 2010 The proftpd Source Code contains a backdoor
    January 2011 Sourceforge, one of the biggest distributor of free software,
got hacked.
    June 2011 The Wordpress Plugins AddThis, WPtouch and W3 Total Cache
contain backdoors
    July 2011 The vsftpd server download was replaced with a hacked version
    July 2011 VLC suffers from Companies spreading Malware bundled with VLC
    August 2011 kernel.org got hacked
    September 2011 MySQL.com hacked to server malware
    November 2011 Takedown of the largest botnet ever. DNS resolving of the
bots was compromised.
    December 2011 Does download.com enrich their downloads with malware?
    February 2012 unnoticed for 3 months, the Horde project served compromised
downloads

I think as a start it should be made a policy that any "wrapper" package that
downloads code from the net must at least do a strong checksum check on the
downloaded code.

What about a debhelper script that receives an URL (or set of mirror URLs) and
a SHA1 and does the download and check?

Regards,

Thomas Koch, http://www.koch.ro

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Benjamin Drung-4
Am Samstag, den 18.02.2012, 11:48 +0100 schrieb Thomas Koch:
>     July 2011 VLC suffers from Companies spreading Malware bundled with VLC

This is no problem for us, because the malware was distributed on some
untrustworthy websites. We, as packagers, get the code directly from the
Videolan project.

--
Benjamin Drung
Debian & Ubuntu Developer

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Jakub Wilk-4
In reply to this post by Christoph Anton Mitterer-2
* Christoph Anton Mitterer <[hidden email]>, 2012-02-18, 06:09:

>I've decided that I think it's important to CC this d-d:
>Debian has a good system of securing packages and making sure that only
>signed stuff comes to the user.
>Over time I've seen many holes in this:
>- packages that are just wrapper packages, download something from
>somewhere without doing any hashsum checks at all
>Some firmware packages, some font packages, documentation etc. is/was
>like that.
>- packages that eventually run some code which was downloaded
>unsecured.
>debootstrap used to be like that, pbuilder, and some others

All(/most?) of those would be RC bugs.
I'll add to the list:
- Packages that download and run untrusted code at build time.

>- Some packages load and process content that could be secured but
>(is/was) not.
>  IIRC the Contents Files are not signed and therefore e.g. apt-file
>cannot secure this.

FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't
verify the signature. But why is that a big deal?

>Of those who actually DID checks, there were several that used weak
>checks (even though there was no need to),... e.g. things like MD5
>checks instead of something "better".
>
>For many of those I've reported bugs (and I'm sure I didn't found a lot
>of them, and I'm further sure that new cases were introduced).
>Some where closed, some where just ignored or denied.

Could you point us to those which were ignored or denied?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120218113214.GA2013@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Neil Williams-4
On Sat, 18 Feb 2012 12:32:14 +0100
Jakub Wilk <[hidden email]> wrote:

> * Christoph Anton Mitterer <[hidden email]>, 2012-02-18, 06:09:
> >I've decided that I think it's important to CC this d-d:
> >Debian has a good system of securing packages and making sure that only
> >signed stuff comes to the user.
> >Over time I've seen many holes in this:
> >- packages that are just wrapper packages, download something from
> >somewhere without doing any hashsum checks at all
> >Some firmware packages, some font packages, documentation etc. is/was
> >like that.
> >- packages that eventually run some code which was downloaded
> >unsecured.
> >debootstrap used to be like that, pbuilder, and some others
Only a bug if this happens by default.

It is perfectly acceptable to support an option to disable SecureApt -
just as long as this is not the default. Tools in Debian need to work
with systems outside Debian and those do not necessarily *need*
SecureApt because the entire loop is internal or even local to the one
machine.

> All(/most?) of those would be RC bugs.
> I'll add to the list:
> - Packages that download and run untrusted code at build time.

...if on Debian buildds or by default.

Private buildd's, by a selectable option - not a bug.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/


attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Neil Williams-4
In reply to this post by Thomas Koch-11
On Sat, 18 Feb 2012 11:48:27 +0100
Thomas Koch <[hidden email]> wrote:

> I think as a start it should be made a policy that any "wrapper" package that
> downloads code from the net must at least do a strong checksum check on the
> downloaded code.

Not possible to enforce as a 'MUST' because, by definition, third-party
websites will not provide checksums for every possible download
mechanism.

Only a should is possible here - wherever a checksum can be verified
independently, but even then, an unreliable upstream checksum method is
better ignored than supported.
 
> What about a debhelper script that receives an URL (or set of mirror URLs) and
> a SHA1 and does the download and check?

Do you mean dget? If it's mirror URL's, most of the time you can use
apt.

If it's mirrors, fine. Anything downloaded from a site which is not
part of *.debian.org or a mirror of *.debian.org cannot be expected to
provide useful checksums.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/


attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Henrique de Moraes Holschuh
In reply to this post by Teus Benschop-2
On Sat, 18 Feb 2012, Teus Benschop wrote:
> To put things in perspective, I just wonder how strong this 'fortress'
> really is, and whether this strength is only in our perception or
> whether it is real. Let me give just one example: A developer downloads
> a tarball from an upstream source, configures it, and does make install,
> yet has not even once checked whether this tarball is secure or is not a
> root kit. Teus.

Good packaging developers go to great lengths to be sure they are not
going to distribute anything trojaned.  This takes a lot of work, and
often requires very goot working relationship with upstream to the point
of getting upstream to change his processes.  This does include tracking
deviations from VCS to upstream releases, going over upstream changes
when possible, and using crypto properly to verify authenticity of
upstream commits and tarballs (when available.  When it is not
available, educating upstream about it is required).

Obviously, sometimes due diligence is not done (some people are quite
lazy), and sometimes it is just plain impossible to do.  And sometimes
the malicious change was done in such way that only a careful audit
would find it.

So, yes, you really risk it happening.  If you want to minimize that
chance, Debian stable is your friend as the window of opportunity to
discover trojaned sources is much larger in stable than it is in testing
and unstable.

I'm not sure what the Debian project could do to make sure we're at
least doing everything that is humanly possible, *on every package* (we
already do it on many packages) to allow for early detection of trojaned
upstream releases or trojaned upstream VCS.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120218124650.GC20674@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Ansgar Burchardt-8
In reply to this post by Jakub Wilk-4
Jakub Wilk <[hidden email]> writes:
> Could you point us to those which were ignored or denied?

At least pbuilder still disables secure APT by default, see #579028.

Regards
Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/8762f4cmh1.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Josselin Mouette
In reply to this post by Christoph Anton Mitterer-2
Le samedi 18 février 2012 à 06:09 +0200, Christoph Anton Mitterer a
écrit :
> Personally I decided to use GNOME-fallback, but via the meta-packages I
> still got the GNOME shell... today
> I've noticed that it silently installs an extension, which (I can only
> assume this by the little
> description) does some software installation/enabling for GNOME shell
> from extensions.gnome.org.
> To me this sounds more like a root-kit than a feature.

No GNOME shell extension is ever downloaded without your consent. The
browser plugin is only here to make this possible. Plugin integrity is
guaranteed by SSL, and extensions have been checked before being put on
the website.

Anyway this doesn’t work very well so we’d be better with just putting
those extensions in another Debian package, but I see this more as a
functional problem than a security one.

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Teus Benschop-2
Am 18.02.2012 10:11, schrieb Teus Benschop:

> To put things in perspective, I just wonder how strong this
> 'fortress'
> really is, and whether this strength is only in our perception or
> whether it is real. Let me give just one example: A developer
> downloads
> a tarball from an upstream source, configures it, and does make
> install,
> yet has not even once checked whether this tarball is secure or is
> not a
> root kit.

This is true but...
a) this would be a general attack against all people, which are usually
a tiny bit harder to do, then the local sysadmin just hacking
colleagues..
b) as everyone is affected then (all users of the package),... there is
a greater chance of notifying it

most important...
c) the ideal situation would of course be, that the maintainer has a
good relationship to upstream, perhaps even met them in person,
exchanged OpenPGP keys with them and uses those (or weaker means[0]) to
verify every single download.


Cheers,
Chris.


[0] Some projects secure their sites e.g. with X.509 certs by one of
the commercial CAs.... I guess this is better than nothing, but many
recent cases have shown us that the whole strict hierarchical trust
model by X.509 is basically for trash.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/29f4cc7dc550446fc47e078c3c727108@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Benjamin Drung-4
Am 18.02.2012 13:14, schrieb Benjamin Drung:
> This is no problem for us, because the malware was distributed on
> some
> untrustworthy websites. We, as packagers, get the code directly from
> the
> Videolan project.

So you meet them once in person and exchanged some kind of PKI/shared
secret etc?
That's great then of course and the ideal case of securely getting the
sources as a maintainer :-)

But I guess only a small fraction of our packages have such a secure
trust path to their upstream.


Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/c6728367706314e815f09031fceddeb1@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Jakub Wilk-4
In reply to this post by Ansgar Burchardt-8
* Ansgar Burchardt <[hidden email]>, 2012-02-18, 14:14:
>>Could you point us to those which were ignored or denied?
>At least pbuilder still disables secure APT by default, see #579028.

The bug is closed. Am I missing something?

But anyway, this is saddening. Hundreds (? - wild guess) of developers
have been building their packages in insecure environment, yet pbuilder
maintainer and a member of Security Team believe that it was a feature,
not a bug. :|

--
Jakub Wilk


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120218141858.GA5960@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Jakub Wilk-4
Am 18.02.2012 13:32, schrieb Jakub Wilk:
> I'll add to the list:
> - Packages that download and run untrusted code at build time.
May I add a similar case...
Take the non-free flash as example... (yeah I know it's non-free and
not officially sec-supported)..
Even if it would use some SHA512 sums (hardcoded into the package) to
verify the download (I don't know whether it does),.. the update
mechanism is still outsite of the package management system (on has to
call update-flash or something like that)... so you bypass the whole
central point of update management.


> FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't
> verify the signature.
See #515942.


> But why is that a big deal?
What do you mean? Of not verifying it? Well as always someone can
attack you if you somehow (for whatever reason) rely on the information
being correct.
Moreover, if there is some automatic parsing of those files, you can
also easily think of attack vectors by manipulating files,..


> Could you point us to those which were ignored or denied?
Phew... would have to do a lot of digging in my mails and bug reports
to find them out again.


Cheers,
Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1ef6a4f196a3cdd6cab0b5940cbf4da5@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Neil Williams-4
Am 18.02.2012 14:34, schrieb Neil Williams:

>> >- packages that eventually run some code which was downloaded
>> >unsecured.
>> >debootstrap used to be like that, pbuilder, and some others
>
> Only a bug if this happens by default.
>
> It is perfectly acceptable to support an option to disable SecureApt
> -
> just as long as this is not the default. Tools in Debian need to work
> with systems outside Debian and those do not necessarily *need*
> SecureApt because the entire loop is internal or even local to the
> one
> machine.

Agreed,.... but it WAS the default till recently,.. e.g. in debootstrap
till 1.0.30, when my bug #560038 was fixed (thanks Joey :) ).
And of course anything that used debootstrap (e.g. pbuilder, piuparts
do so) was automatically insecure, too. (till then)


Cheers,
Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/121005584832f4d35086604441f2166a@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Neil Williams-4
Am 18.02.2012 14:40, schrieb Neil Williams:
>> I think as a start it should be made a policy that any "wrapper"
>> package that
>> downloads code from the net must at least do a strong checksum check
>> on the
>> downloaded code.
> Not possible to enforce as a 'MUST' because, by definition,
> third-party
> websites will not provide checksums for every possible download
> mechanism.

Well it's still possible then,... the maintainer can just calculate
sums on his own.
Of course this does not mean things are secure (the maintainer could
already use a forged version)... but at least it helps again single MITM
attacks.


Cheers,
Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/0a9d69dc96c647151114bca2d8ebbdf9@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Christoph Anton Mitterer-2
In reply to this post by Josselin Mouette
Am 18.02.2012 15:30, schrieb Josselin Mouette:

>> Personally I decided to use GNOME-fallback, but via the
>> meta-packages I
>> still got the GNOME shell... today
>> I've noticed that it silently installs an extension, which (I can
>> only
>> assume this by the little
>> description) does some software installation/enabling for GNOME
>> shell
>> from extensions.gnome.org.
>> To me this sounds more like a root-kit than a feature.
>
> No GNOME shell extension is ever downloaded without your consent. The
> browser plugin is only here to make this possible. Plugin integrity
> is
> guaranteed by SSL, and extensions have been checked before being put
> on
> the website.

Well I guess the problem here are three things:
- Communication
You say now, that GNOME checks all what they put up there, and nothing
is every installed automatically.
This makes things a bit better,... but it's not really obviously
documented.
At least not for a just-a-user like me. Of course one can always say
read the code + go into the developer docs,... but if I have to do this
for everything, than I'm just screwed.

- Trust
I really do not trust GNOME/Mozilla etc. here do do all this in a
secure and right way.
At least for Mozilla there are hundredths of extensions, they surely
can't check them all.

- Bypassing the package management system
IMHO, software in Debian should ONLY be installed by the package
management system with one exception:
When the user really downloads/(optionally compiles)/installs himself.
Especially software should not bring its own package management system
in form of app-store-like thingies.

Of course I know it's difficult to prevent this. Upstreams just do
it... and ways around it (e.g. our Mozilla Extension Packages) are a big
effort for us.
Nevertheless, solve this via packages, would be the right way (IMHO).


> Anyway this doesn’t work very well so we’d be better with just
> putting
> those extensions in another Debian package, but I see this more as a
> functional problem than a security one.

Great :)


Cheers,
Chris.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/74ac1eea31fb134b60c8ef405d67683c@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Jakub Wilk-4
In reply to this post by Christoph Anton Mitterer-2
* Christoph Anton Mitterer <[hidden email]>, 2012-02-18, 16:19:
>Take the non-free flash as example... (yeah I know it's non-free and
>not officially sec-supported)..
>Even if it would use some SHA512 sums (hardcoded into the package) to
>verify the download (I don't know whether it does),.. the update
>mechanism is still outsite of the package management system (on has
>to call update-flash or something like that)... so you bypass the
>whole central point of update management.

Completely agreed! We should remove flashplugin-nonfree from the
archive. Or wait, even simpler, you could just not install it.

>>FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't
>>verify the signature.
>See #515942.

You can easily check yourself that Contents-* checksums are mentioned in
the Release files, even for lenny. (Though indeed they weren't in Feb
2009.)

Feel free to unarchive and reopen the bug.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120218144754.GA6942@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Ansgar Burchardt-8
In reply to this post by Jakub Wilk-4
Jakub Wilk <[hidden email]> writes:
> * Ansgar Burchardt <[hidden email]>, 2012-02-18, 14:14:
>>>Could you point us to those which were ignored or denied?
>>At least pbuilder still disables secure APT by default, see #579028.
>
> The bug is closed. Am I missing something?

pbuilder was changed to pass the --keyring argument to debootstrap by
default and there now is an option to enable secure apt, but it is still
disabled by default.

Regards,
Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87zkcgb1ko.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: leaks in our only-signed-software fortress

Neil Williams-4
In reply to this post by Christoph Anton Mitterer-2
On Sat, 18 Feb 2012 16:25:20 +0200
Christoph Anton Mitterer <[hidden email]> wrote:

> Am 18.02.2012 14:40, schrieb Neil Williams:
> >> I think as a start it should be made a policy that any "wrapper"
> >> package that
> >> downloads code from the net must at least do a strong checksum check
> >> on the
> >> downloaded code.
> > Not possible to enforce as a 'MUST' because, by definition,
> > third-party
> > websites will not provide checksums for every possible download
> > mechanism.
>
> Well it's still possible then,... the maintainer can just calculate
> sums on his own.
Against what? The source is only downloaded from upstream once per
upstream release, what is there to check against?

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/


attachment0 (205 bytes) Download Attachment
123