Re: md5sums files

[Neil Williams]

On Wed, 3 Mar 2010 08:35:18 +0100
Mike Hommey  wrote:

> On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote:
> > 
> > The md5 sums isn't to be used in case of a break in, as you can't trust
> > anything on the system anyways, but more things like:
> >  - did I make; sudo make install something on top of packages
> >  - did I just quickly hack a p{erl,ython}-script on the system to do
> >something different and forgot
> 
> Which makes me think... wouldn't it be nice from dpkg to check the
> package files haven't been modified before upgrading ?

No - if you're upgrading, you're doing it because you want to be sure
that the Debian version replaces the old version. However, if you do
use 'make; sudo make install; with a prefix of /usr instead
of /usr/local then a) you're taking a risk and b) md5sums are only a
partial protection. md5sums will NOT catch instances where the upstream
'make install' provides files that are not part of the Debian package
nor will it catch files that have been moved as part of Debian
packaging. As these files are not put into place by dpkg anyway, then
they won't get cleaned up by dpkg and cannot be detected either by
using md5sums or by using dpkg. (dpkg will complain that certain
directories are not empty if the packaged files being upgraded are in
special places but not otherwise.) There's every chance that having
extraneous and/or duplicate content in the wrong places will break the
Debian package in ways that are not easily detectable and md5sums won't
help with that.

Having md5sums around for simple checks like local admins copying
modified scripts over packaged versions is one thing but IMHO it does
not justify having md5sums in the wider case because a) local admin
changes are the responsibility of the local admin and b) md5sums only
help detect those changes where the admin changes a filename that
exactly matches the packaged name rather than adding more content /
cruft.

'sudo make install' into /usr is not something that md5sums can help us
fix and if that is the sole justification for retaining them then I
think that is a false argument.

Debian does move a lot of files around during packaging (the recent
stipulation against files in /var/www/ is just one instance) - my own
feeling is that the very packages that DO have their files moved around
for FHS reasons are the very ones that (some) local admins may want to
install from upstream tarballs ahead of the Debian package being
updated. Moving files invalidates any protection from having the
md5sum - unless the local admin retains a separate list of which files
have been installed separately, but then I thought the idea was that
such a record would be available by installing into /usr/local instead
of /usr in the first place. ;-)

Changing to SHA won't help. I'm for ditching all md5sums from packages.
It's not a lot of disc space gained but it does give a false sense of
security or 'insurance' if you want to avoid the more formal meaning of
'security'.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpGQsxssIvRd.pgp
Description: PGP signature

Re: md5sums files

[Philipp Kern]

On 2010-03-03, Neil Williams  wrote:
> Changing to SHA won't help. I'm for ditching all md5sums from packages.
> It's not a lot of disc space gained but it does give a false sense of
> security or 'insurance' if you want to avoid the more formal meaning of
> 'security'.

Please don't.  It's not about security.  It's about being able to detect
corruption.  Also it is very helpful when recovering from ext4 root FS
corruption after a sudden power loss.  Sure, you cannot guarantee that
the md5 store isn't corrupted too but if it isn't then debsums is
helpful.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhos7oj.qn5.tr...@kelgar.0x539.de

Re: md5sums files

[Mike Hommey]

On Wed, Mar 03, 2010 at 08:29:09AM +, Neil Williams wrote:
> On Wed, 3 Mar 2010 08:35:18 +0100
> Mike Hommey  wrote:
> 
> > On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote:
> > > 
> > > The md5 sums isn't to be used in case of a break in, as you can't trust
> > > anything on the system anyways, but more things like:
> > >  - did I make; sudo make install something on top of packages
> > >  - did I just quickly hack a p{erl,ython}-script on the system to do
> > >something different and forgot
> > 
> > Which makes me think... wouldn't it be nice from dpkg to check the
> > package files haven't been modified before upgrading ?
> 
> No - if you're upgrading, you're doing it because you want to be sure
> that the Debian version replaces the old version. However, if you do
> use 'make; sudo make install; with a prefix of /usr instead
> of /usr/local then a) you're taking a risk and b) md5sums are only a
> partial protection. md5sums will NOT catch instances where the upstream
> 'make install' provides files that are not part of the Debian package
> nor will it catch files that have been moved as part of Debian
> packaging. As these files are not put into place by dpkg anyway, then
> they won't get cleaned up by dpkg and cannot be detected either by
> using md5sums or by using dpkg. (dpkg will complain that certain
> directories are not empty if the packaged files being upgraded are in
> special places but not otherwise.) There's every chance that having
> extraneous and/or duplicate content in the wrong places will break the
> Debian package in ways that are not easily detectable and md5sums won't
> help with that.
> 
> Having md5sums around for simple checks like local admins copying
> modified scripts over packaged versions is one thing but IMHO it does
> not justify having md5sums in the wider case because a) local admin
> changes are the responsibility of the local admin and b) md5sums only
> help detect those changes where the admin changes a filename that
> exactly matches the packaged name rather than adding more content /
> cruft.
> 
> 'sudo make install' into /usr is not something that md5sums can help us
> fix and if that is the sole justification for retaining them then I
> think that is a false argument.

My point is that these people doing that, or even better, people doing
an upgrade on a system where other people have been doing that would
probably *want* to have a warning about the fact that the files dpkg is
going to replace did *not* match what was supposed to be there in the
first place.

That would also possibly help spot filesystem errors, because when
upgrading, dpkg is not going to write to the same places where the
previous versions of the files were, and when it finishes upgrading, it
will just remove the previous files and the corruptions, especially if
they are due to hardware problems, will still be unnoticed and may
affect more important data much later, when the freed space is used
again.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303084209.ga20...@glandium.org

Re: Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza

[Charles Plessy]

Hello everybody,

Le Tue, Mar 02, 2010 at 02:04:56PM +0100, Raphael Hertzog a écrit :
> On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
> > On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> > > The substvars approach sounds good to me. I think I'd use it quite a lot,
> > > specially in libraries.
> > 
> > That, however, does not solve the problem of how to access a source
> > package description from infrastructure tools such as DDPO, the PTS,
> > etc.

Moreover, debhelper does not check debian/substvars (at least it did not a
couple of monthes ago), but debian/.substvars, so the
source description would have to be in an unexpected place (or a bug should be
reported on debhelper).


> The sensible answer is putting this information in the .dsc and thus in
> the Sources files. But it means that the file would get somewhat bigger
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

In the long term, we could aim at separating the dpkg meta-data, like the
Source, Package, Architecture, Depends, etc. fields, from the archive
meta-data, like the Vcs-*, DM-Upload-Allowed, Section, Priority, etc. fields.
All the Debian system is aptable anyway, so the Description could be also be
considered archive meta-data without information loss. Unfortunately, this is
perhaps inconvenient for third-party packages.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303093955.gb19...@kunpuu.plessy.org

Re: md5sums files

[Roland Mas]

Wouter Verhelst, 2010-03-03 03:06:20 +0100 :

[...]

> In this day and age of completely and utterly broken MD5[0], I think
> we should stop providing these files, and maybe provide something else
> instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop
> providing md5sums.
>
> Or is it useful to be able to say "if it doesn't check out, it's
> certainly corrupt, and if it does check out, it may be corrupt"?
> Didn't think so.

It is useful.  Not too efficient against attacks, I'll grant you, but
there are other use cases.  One of those I run into from time to time,
as maintainer of servers with webapps, is that I want to know from time
to time if there have been local changes in installed files when
compared to the (already custom) packages, so I can have a look and
integrate the changes into the next version of the custom packages.  The
suggestion of having dpkg warn me on upgrade is interesting, but to be
proactive I'm happy to run debsums on my own before the deployment
stage.  Because when you're in a deployment rush and one of the files
lacks a semicolon and breaks the whole app, you just $EDITOR
/usr/share/.../foo.php; some other times, your client messes with their
CSS files locally, and you don't want to be grumbled at if you lose that
change, even if you (and the client) know that the change *should* have
been done in the packages in the first place.

  I'm quite okay with replacing or complementing the md5sums with
something stronger if it helps with security, but removing them
altogether… please no.

Roland.
-- 
Roland Mas

La menace de la baffe pèse plus lourd que la baffe elle-même.
  -- in Sri Raoul le petit yogi (Gaudelette)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87iq9du42q@mirexpress.internal.placard.fr.eu.org

Re: Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza

[Goswin von Brederlow]

Stefano Zacchiroli  writes:

> On Tue, Mar 02, 2010 at 11:05:14AM +0100, Raphael Hertzog wrote:
>> > 0) (Starting intuition) most source package have a description per se,
>> >intuitively, that is the same description you'd find on the upstream
>> >homepage that made you download a specific software. Sure different
>> >binary packages can have different specific purpose, but it is in
>> >most cases possible to have a single all-encompassing description.
>> 
>> Should that description be exported in the .dsc then ?
>
> It is not clear to me what would be the pro/cons of having the
> description there, so I cannot tell. However, if the rationale of the
> current information in .dsc is currently "all source package information
> are there", then yes, it would make sense (even though I don't care that
> much).

I think there are 2 things here:

1) Add a description to *.dsc

This would be just for packages.d.o or apt-cache showsrc. Buildd admins
could find it also usefull so they can quickly see what a package is
about without first having to lookup what binary packages a source
builds.

2) Factoring out a common paragraph from binary descriptions

If I understood this right the source description would be put into
substvars automatically and the binary description can then reuse that
variable.

This would make many control files smaller and avoid duplication of
text.  Chaning the common text would only need a change at one place
then.


I think both things are a good idea.

>> [ Skipping tools that would benefit from the information ]
>
> Fair enough. Still, for the others interesting to comment on this
> wishlist bug report, please check the original bug report to know which
> tools and infrastructure parts would benefit. It is quite a relevant set
> of tools.
>
>> > 2) A frequent pattern in debian/control is as follows:
> 
>> If I do something like that it's rather with substvars. You could use
>> ${source:Description:body} and ${source:Description:title} in the binary
>> package description to refer to the the corresponding parts of the source
>> description.
>
> That it *can* be currently implemented using substvars is clear. As
> usual however, there is a trade-off between expressivity of the current
> tool set (i.e. it can be done) and convenience (i.e. how easy it is). I
> believe currently no one is doing that, but I'm also convinced that if
> supported out of the box it will become a quite handy feature to reduce
> information duplication and be kind with various parts of our toolchain.

But currently one would have to manually set the substvar and the text
it is set too would come from somewhere unintuitive. By having dpkg set
the substvar from the source description and ha ving this properly
documented it would make it obvious where the text comes from and allow
for easy translation.

Using a substvar gives the maintainer the flexibility to decide which
binary packages should have the common stanza included and which don't.
E.g. you could have 2 packages with the stanza and a third with a
completly different description.

>> I think it's ok. But some more feedback would be welcome, CCing -devel
>> for this.
>
> Thanks for the feedback and for the initiative.
>
> Cheers.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874okxn1ly@frosties.localdomain

Re: md5sums files

[Goswin von Brederlow]

Erik de Castro Lopo  writes:

> Russ Allbery wrote:
>
>> Wouter Verhelst  writes:
>> 
>> > Or is it useful to be able to say "if it doesn't check out, it's
>> > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
>> > think so.
>> 
>> I don't understand why you say this.  Cryptographic attacks on MD5 aren't
>> going to happen as a result of random file corruption.  The MD5 checksums
>> are still very effective at finding file corruption or modification from
>> what's in the Debian package unless that modification was done by a
>> sophisticated attacker (MD5 preimage attacks are still not exactly easy).
>> Detecting compromises is useful, but only a small part of what the MD5
>> checksums are useful for.
>
> If the machine has been compromised, *nothing* on the machine can be
> trusted, whether its gpg signed or not. However, for detecting corruptions

Surely you are wrong. While you can not trust the gpg binary on the
compromised system the signatures will still hold. You just need to boot
from a live CD and use a garantied clean gpg and keyring to verify them.

> and the local sysadmin meddling Russ mentioned, md5sum is more than adequate
> and using something 'more secure' than md5sum is overkill.

Due to the lack of a signature on the md5sum file the file can not be
tusted fo security purposes at all. And for detecting unintentional
changes md5sum is plenty strong enough.

But imagine the file would be signed or a signature could be gotten
through a safe channel. Then the file could be used for a security audit
as well and something stronger would be benefitial. A simple way would
be create a shasum file (instead of md5) and to include a hash of said
file in Packages.gz. 

> Erik

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zl2plmca@frosties.localdomain

Re: md5sums files

[Goswin von Brederlow]

Mike Hommey  writes:

> On Wed, Mar 03, 2010 at 08:29:09AM +, Neil Williams wrote:
>> On Wed, 3 Mar 2010 08:35:18 +0100
>> Mike Hommey  wrote:
>> 
>> > On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote:
>> > > 
>> > > The md5 sums isn't to be used in case of a break in, as you can't trust
>> > > anything on the system anyways, but more things like:
>> > >  - did I make; sudo make install something on top of packages
>> > >  - did I just quickly hack a p{erl,ython}-script on the system to do
>> > >something different and forgot
>> > 
>> > Which makes me think... wouldn't it be nice from dpkg to check the
>> > package files haven't been modified before upgrading ?
>> 
>> No - if you're upgrading, you're doing it because you want to be sure
>> that the Debian version replaces the old version. However, if you do
>> use 'make; sudo make install; with a prefix of /usr instead
>> of /usr/local then a) you're taking a risk and b) md5sums are only a
>> partial protection. md5sums will NOT catch instances where the upstream
>> 'make install' provides files that are not part of the Debian package
>> nor will it catch files that have been moved as part of Debian
>> packaging. As these files are not put into place by dpkg anyway, then
>> they won't get cleaned up by dpkg and cannot be detected either by
>> using md5sums or by using dpkg. (dpkg will complain that certain
>> directories are not empty if the packaged files being upgraded are in
>> special places but not otherwise.) There's every chance that having
>> extraneous and/or duplicate content in the wrong places will break the
>> Debian package in ways that are not easily detectable and md5sums won't
>> help with that.
>> 
>> Having md5sums around for simple checks like local admins copying
>> modified scripts over packaged versions is one thing but IMHO it does
>> not justify having md5sums in the wider case because a) local admin
>> changes are the responsibility of the local admin and b) md5sums only
>> help detect those changes where the admin changes a filename that
>> exactly matches the packaged name rather than adding more content /
>> cruft.
>> 
>> 'sudo make install' into /usr is not something that md5sums can help us
>> fix and if that is the sole justification for retaining them then I
>> think that is a false argument.
>
> My point is that these people doing that, or even better, people doing
> an upgrade on a system where other people have been doing that would
> probably *want* to have a warning about the fact that the files dpkg is
> going to replace did *not* match what was supposed to be there in the
> first place.
>
> That would also possibly help spot filesystem errors, because when
> upgrading, dpkg is not going to write to the same places where the
> previous versions of the files were, and when it finishes upgrading, it
> will just remove the previous files and the corruptions, especially if
> they are due to hardware problems, will still be unnoticed and may
> affect more important data much later, when the freed space is used
> again.
>
> Mike

Run a nightly/weekly cron job that verifies all files. No point waiting
for a package upgrade to check this.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vdddlm95@frosties.localdomain

Re: md5sums files

[Wouter Verhelst]

On Wed, Mar 03, 2010 at 03:17:52PM +1100, Erik de Castro Lopo wrote:
> Russ Allbery wrote:
> 
> > Wouter Verhelst  writes:
> > 
> > > Or is it useful to be able to say "if it doesn't check out, it's
> > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> > > think so.
> > 
> > I don't understand why you say this.  Cryptographic attacks on MD5 aren't
> > going to happen as a result of random file corruption.  The MD5 checksums
> > are still very effective at finding file corruption or modification from
> > what's in the Debian package unless that modification was done by a
> > sophisticated attacker (MD5 preimage attacks are still not exactly easy).
> > Detecting compromises is useful, but only a small part of what the MD5
> > checksums are useful for.
> 
> If the machine has been compromised, *nothing* on the machine can be
> trusted, whether its gpg signed or not. However, for detecting corruptions
> and the local sysadmin meddling Russ mentioned, md5sum is more than adequate

Sure, I'm not contesting that.

> and using something 'more secure' than md5sum is overkill.

This is where I disagree. When a checksum algorithm is compromised (and
MD5 *is* compromised), things only ever get worse, not better. Indeed,
MD5 preimage attacks are pretty hard *today*. But switching to something
more secure in preparation for the day when MD5 will be easily cracked
by every script kiddo around is *not* overkill.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303104725.ga18...@celtic.nixsys.be

Re: md5sums files

[Philipp Kern]

On 2010-03-03, Wouter Verhelst  wrote:
> This is where I disagree. When a checksum algorithm is compromised (and
> MD5 *is* compromised), things only ever get worse, not better. Indeed,
> MD5 preimage attacks are pretty hard *today*. But switching to something
> more secure in preparation for the day when MD5 will be easily cracked
> by every script kiddo around is *not* overkill.

Sure, but to be honest, not even all packages managed to generate md5sums
'till now (with some quite core, omnipresent packages missing) so it seems out
of scope for squeeze.  Maybe squeeze+1.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhosifd.rmi.tr...@kelgar.0x539.de

Bug#572325: ITP: xjobs -- reads job descriptions line by line and executes them in parallel

[Stefan Voelkel]

Package: wnpp
Severity: wishlist
Owner: Stefan Voelkel 


* Package name: xjobs
  Version : 20100203
  Upstream Author : Thomas Maier-Komor 
* URL : http://www.maier-komor.de/xjobs.html
* License : GPL
  Programming Lang: C
  Description : reads job descriptions line by line and executes them in 
parallel

 It limits the number of parallel executing jobs and starts new jobs when jobs
 finish. Therefore, it combines the arguments from every input line with the
 utility and arguments given on the command line. If no utility is given as an
 argument to xjobs, then the first argument on every job line will be used as
 utility. To execute utility xjobs searches the directories given in the PATH
 environment variable and uses the first file found in these directories.
 .
 xjobs is most useful on multi-processor/core machines when one needs to
 execute several time consuming command several that could possibly be run in
 parallel. With xjobs this can be achieved easily, and it is possible to limit
 the load of the machine to a useful value. It works similar to xargs, but
 starts several processes simultaneously and gives only one line of arguments
 to each utility call.

>From the webpage:

Comment on GNU xargs vs. xjobs

Yes, GNU's xargs has an option -P that allow parallelizing jobs. But you must
tell xargs how many arguments to pass to each job, as it doesn't make a
difference between a space and a newline charakter. In consequence each job
issued by xargs must have the same number of arguments, whereas xjobs can
handle different jobs with different commands and different number of
arguments.

Additionally, xjobs support I/O redirection, which makes some applications
possible that cannot be done with GNU's xargs. xjobs also determines the number
of processors automatically, whereas xargs must be told how many processes to
start. Finally, non-GNU xargs (e.g. Solaris' and DEC/Compaq/HP Alpha's) don't
have the option -P. Try to do the following with GNU's xargs with some files
having blanks in their name:

* ls -1 *.mp3 | sed 's/\(.*\)\.mp3/"\1.mp3" > "\1.wav"/' | xjobs -- mpg123 
-s

If you aren't convinced yet, just compare the output of unziping multiple zip
files in parallel with xjobs and GNU xargs. xjobs won't intermix the output of
unzip like xargs. Instead it will present the output of each unzip separated
clearly from the other jobs. 

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303120311.19480.4683.report...@bc-bd.org

Re: Bug#545782: imagemagick-dbg: missing README.Debian to explain how programs are used

[Bastien ROUCARIES]

Any progress on this bug ?

On Sun, Dec 27, 2009 at 8:26 PM, Nelson A. de Oliveira
 wrote:
> Hi!
>
> On Sun, Dec 27, 2009 at 10:14 AM, Jari Aalto  wrote:
>> Repoening, this doesn't address the original bug report titled "missing
>> README.Debian to explain how programs are used". Please provide
>> instructions how to use those files with gdb in order to examine
>> problems with imagemagick problems.
>>
>> There could be even a use case how to start debugging some of the
>> programs, like "convert".
>
> The problem here is that we have a lot of -dbg packages on Debian, all
> of them containing binaries under /usr/lib/debug/
> Do we need the same README file on all of them? We will have more than
> a thousand equal READMEs on the archive, explaining the same thing.
> I don't think that a file explaining how to use them with gdb belongs
> to imagemagick-dbg (nor any other -dbg packages).
>
> My view is that, if necessary, the package maintainer is responsible
> in helping the user to get a backtrace (by pointing how to use gdb,
> install the -dbg package, etc).
> Or at least an explanation in the gdb package only.
>
> CCing debian-devel to see if we can get better opinions and solutions for 
> this.
>
> Best regards,
> Nelson
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/195c7a901003030447p458a3d44h83d64ef5ee937...@mail.gmail.com

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote:
> In this day and age of completely and utterly broken MD5[0], I think we
> should stop providing these files, and maybe provide something else
> instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing
> md5sums.
> 
> Or is it useful to be able to say "if it doesn't check out, it's
> certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> think so.

As a means to check for filesystem corruptions or non-malicious changes,
MD5 is good enough. So until we have something better, I guess they can
stay.

But it would be great if the whole chain, from beginning to end, was
secured, even against a malicious and presumably very powerful attackers.
That would need:
  * Package signatures
Currently only the release file is signed, but if you have a package
lying around, there is no way to check its authenticity.
  * Cryptographically strong hashes for all files in the package 
and a signature on the hash file.
Then you could really check the authenticity of all files on the system.
For the hash I would skip SHA-1 and move directly to SHA-256.

Oh, and a good read about the lifetime of hash algorithms can be found here: [0]

Cheers,
harry

[0] http://valerieaurora.org/hash.html




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303133905.gb11...@nn.nn

Re: md5sums files

[Mike Hommey]

On Wed, Mar 03, 2010 at 02:39:05PM +0100, Harald Braumann wrote:
> On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote:
> > In this day and age of completely and utterly broken MD5[0], I think we
> > should stop providing these files, and maybe provide something else
> > instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing
> > md5sums.
> > 
> > Or is it useful to be able to say "if it doesn't check out, it's
> > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> > think so.
> 
> As a means to check for filesystem corruptions or non-malicious changes,
> MD5 is good enough. So until we have something better, I guess they can
> stay.
> 
> But it would be great if the whole chain, from beginning to end, was
> secured, even against a malicious and presumably very powerful attackers.
> That would need:
>   * Package signatures
> Currently only the release file is signed, but if you have a package
> lying around, there is no way to check its authenticity.
>   * Cryptographically strong hashes for all files in the package 
> and a signature on the hash file.
> Then you could really check the authenticity of all files on the system.
> For the hash I would skip SHA-1 and move directly to SHA-256.
* A way to easily create a bootable device (usb, cd, whatever) that
  will check everything is in order. Extra points if that is part of
  the rescue images on the install CDs.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303135212.ga13...@glandium.org

Bug#572338: ITP: php-net-whois -- PHP PEAR module for querying whois services

[Dario Minnucci]

Package: wnpp
Severity: wishlist
Owner: Dario Minnucci 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: php-net-whois
  Version : 1.0.2
  Upstream Author : Seamus Venasse 
* URL : http://pear.php.net/package/Net_Whois
* License : PHP 3.01
  Programming Lang: PHP
  Description : PHP PEAR module for querying whois services

 The PEAR::Net_Whois class provides a tool to query internet domain name and
 network number directory services.
 .
 The PEAR::Net_Whois looks up records in the databases maintained
 by several Network Information Centers (NICs).


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJLjmg/AAoJEPyEGy2CyLcRA6sP/0hgQbCYLqoDFrUOHY9hOtDj
7yxSpaMqYUE2hunswzG4qSgk/sLG8muZ24r74Cj+iBNWZHxNQTCHZsppm0rWsi8/
AGa8M8Rp6/LV9llfMWzMZcGv5D6GPzmc9byOVv47TbcDDY0z/TI34ilU6o1BMp0E
7ZDGKx+ez6FRHB/ciZMq8qgkhi+Hl5HJb2aDCMlg1W4z7xZgEOYiZTkGjyA2KxWt
+19Jn0U4wIu6d9Sx7V8xRzjdMFyEd+9yxM3OUb9HAtIQwp+bW4+xatnRX2VEJk6c
Pyj3NN5JYoYTvUvJ3HwYWWvKIV2Rv+uMOnq0OcROn43gzYjfIkYzNivYNvsJhJaC
b0fhHa01QutK6jlAspvT44fPHcGWNKC6m18rYtiuvO+mAttoDBVRIxpVTx73GhX6
pFkqN7xYPV3tH61X7hP3iMQN+4OYoEoNEcrvxQjW89CZbqQ22DNGj06ljKEXBEvR
+Xu4IrRAIqjLB0ez8qtUFy8TlGeZDgrsAzX5VxlVVIt7Dds/koFyBlJGZBznFHHy
yQm0WI5LD+JKNhOM3nhPeswOhLA4mwo94uQNgM4KnuodatZDt19q/SsiFPl5xPD1
ELAE36qTckthjh+7fX7XxU7YUQviIG4DpBEeOLd0iL8dw8Lg3w19ipm78c9Z1FRX
C96vPf4doBHuP9ojoHvg
=GWbP
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100303134646.7118.40765.report...@dharma.midworld-networks.com

Re: md5sums files

[Bernhard R. Link]

* Harald Braumann  [100303 14:49]:
> As a means to check for filesystem corruptions or non-malicious changes,
> MD5 is good enough. So until we have something better, I guess they can
> stay.

I'd even say they should stay. The shorter the hash the more useable.
And md5 is the shortest well-defined and readily available everywhere.

> But it would be great if the whole chain, from beginning to end, was
> secured, even against a malicious and presumably very powerful attackers.

Checksums for files coming from packages is not really useful to defend
against attackers (it's really only reliablity and not security):

- an attacker can just divert any binary away and put it's own there.
- an attacker can just add some additional binary where it will override
  another one (/sbin overriding /usr/sbin and so on).
- an attacker can add things to configuration and startup files
  (thanks to .d directories you often not even need changing but only
   adding files), including search binary or library paths, so one could
  add binaries or behaviour changing libraries in directories not
  looking that suspicious.

Most of those things can perhaps be fixed, but it needs much work
than just replacing some hash. (And many of those tasks might also
improve other areas (like http://packages.debian.org/cruft also having
the problem that packages create so many files and there is no way a
package can tell such programs where they are).

> For the hash I would skip SHA-1 and move directly to SHA-256.

And not to forget to add the size. Being allowed to create arbitrary
large files makes attacking interated hashes much easier...

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100303141608.ga21...@pcpool00.mathematik.uni-freiburg.de

Re: Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza

[Loïc Minier]

On Tue, Mar 02, 2010, Raphael Hertzog wrote:
> The sensible answer is putting this information in the .dsc and thus in
> the Sources files. But it means that the file would get somewhat bigger
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

 While that seems sensible, I wonder whether it would make sense to
 include the information in Packages.gz instead.  There's a high level
 use case which is not too nicely covered at the moment: if one upgrades
 with a graphical package management tools displaying progress of the
 upgrade, it would typically show which package is being upgraded with
 its description, but you typically upgrade all binary packages from the
 same source at the same time, so in the list of packages to update,
 you'd likely see "The GTK+ graphical user interface library"
 (libgtk2.0-0), "The programs for the GTK+ graphical user interface
 library" (libgtk2.0-bin), "Common files for the GTK+ graphical user
 interface library" (libgtk2.0-common) while it would probably make
 sense to only offer a single entry for the software bundle being
 updated, i.e. for all binary packages provided by the same source, with
 a nice description.

 Now that use case still has a flaw in usability in that even per source
 package descriptions wouldn't mean much to non-developers, so it's
 probably a minor improvement in package managers not worth the effort
 of changing infrastucture etc.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303123459.ga7...@bee.dooz.org

Re: md5sums files

[Loïc Minier]

On Wed, Mar 03, 2010, Wouter Verhelst wrote:
> In this day and age of completely and utterly broken MD5[0], I think we
> should stop providing these files, and maybe provide something else
> instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing
> md5sums.
> 
> Or is it useful to be able to say "if it doesn't check out, it's
> certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> think so.

 I use them regularly after laptop crashes; I found some misinstalled
 packages a couple of times because a crash would happen just after an
 upgrade.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303124010.gb7...@bee.dooz.org

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 03:16:08PM +0100, Bernhard R. Link wrote:
> * Harald Braumann  [100303 14:49]:
> > But it would be great if the whole chain, from beginning to end, was
> > secured, even against a malicious and presumably very powerful attackers.
> 
> Checksums for files coming from packages is not really useful to defend
> against attackers (it's really only reliablity and not security):
> 
> - an attacker can just divert any binary away and put it's own there.
It's not about preventing an attack, but detecting it. With cryptographically
strong hashes/signatures in place, you can audit the system. Of course you'd 
have to boot from a trusted medium. How would you do that without signatures?

> - an attacker can just add some additional binary where it will override
>   another one (/sbin overriding /usr/sbin and so on).
> - an attacker can add things to configuration and startup files
>   (thanks to .d directories you often not even need changing but only
>adding files), including search binary or library paths, so one could
>   add binaries or behaviour changing libraries in directories not
>   looking that suspicious.
Yes, a full IDS needs additional work. It would have to check for files
without hashes/signatures and would have to allow you to hash and sign
files in /etc, /usr/local, /opt, whatever).

> Most of those things can perhaps be fixed, but it needs much work
> than just replacing some hash. (And many of those tasks might also
> improve other areas (like http://packages.debian.org/cruft also having
> the problem that packages create so many files and there is no way a
> package can tell such programs where they are).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303150337.gc11...@nn.nn

Re: md5sums files

[Peter Samuelson]

[Wouter Verhelst]
> I must say I was somewhat surprised by these numbers. Out of 2483
> packages installed on my laptop, 2340 install md5sums.

The surprising part, perhaps, is that dpkg itself didn't just generate
the other 143 md5sums files at installation time.

I suggested this a long time ago and of course was met with "so where's
your patch?"  Of course I was not willing to do the work.  But
fundamentally, shipping a md5sums file is really just a tradeoff in
download size vs. installation speed, not unlike gzip vs. bzip2.  One
can imagine in the future, on architectures where CPU is little
consideration, letting those md5sums files all be generated at install
time.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303160510.gf18...@p12n.org

Re: md5sums files

[Osamu Aoki]

On Wed, Mar 03, 2010 at 11:37:17AM +, Philipp Kern wrote:
> On 2010-03-03, Wouter Verhelst  wrote:
> > This is where I disagree. When a checksum algorithm is compromised (and
> > MD5 *is* compromised), things only ever get worse, not better. Indeed,
> > MD5 preimage attacks are pretty hard *today*. But switching to something
> > more secure in preparation for the day when MD5 will be easily cracked
> > by every script kiddo around is *not* overkill.
> 
> Sure, but to be honest, not even all packages managed to generate md5sums
> 'till now (with some quite core, omnipresent packages missing) so it seems out
> of scope for squeeze.  Maybe squeeze+1.

True but debsums can address these issues by system administrator
touch-ups as documented in manpage using:

 * /etc/apt/apt.conf.d/90debsums (debsums >= 2.0.7)
 * debsums_init(8)   (debsums >= 2.0.34 @ 2007)

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303155453.ga5...@osamu.debian.net

Re: md5sums files

[Osamu Aoki]

Hi,

On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote:
> Hello world,
> 
> wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l
> 2340
> wou...@celtic:/var/lib/dpkg/info$ ls *sums|wc -l
> 2340
> wou...@celtic:/var/lib/dpkg/info$ dpkg -l|sed -e'1,/=/d'|wc -l
> 2483

Here on my system:
$ dpkg -l|sed -e'1,/=/d'|wc -l
2302
$ dpkg -l|sed -e'1,/=/d'|grep ^ii |wc -l
2301
$ dpkg -l|sed -e'1,/=/d'|grep -v ^ii
rc  sbcl 1:1.0.34.0-1  A Common Lisp compiler and development system
So dfference can be explained.

> I must say I was somewhat surprised by these numbers. Out of 2483
> packages installed on my laptop, 2340 install md5sums. While that
> might've been useful at some point, I don't think it still is.

Are you sure you hava all package lines starting with "ii"?

(I know some package may still be lacking *md5sums under some
configuration.  If so, I suggest to read debsums and debsums_init
manpages. This issue is solved since 2007.)
 
> In this day and age of completely and utterly broken MD5[0], I think we
> should stop providing these files, and maybe provide something else
> instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing
> md5sums.

gpg is slow. sha variants will be nice if there is smooth transition in
place properly planned and supprted with backported package of debsums.

The advantage of debsums is precalculated sum values and quick sanity
check capability against random changes.

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303161226.gb5...@osamu.debian.net

Re: md5sums files

[Harald Braumann]

On Thu, Mar 04, 2010 at 01:12:26AM +0900, Osamu Aoki wrote:
>  
> > In this day and age of completely and utterly broken MD5[0], I think we
> > should stop providing these files, and maybe provide something else
> > instead.  Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing
> > md5sums.
> 
> gpg is slow. sha variants will be nice if there is smooth transition in
> place properly planned and supprted with backported package of debsums.

You wouldn't sign each file, just the hash sums file.

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303175954.gd11...@nn.nn

Re: Removing the manpage requirement for GUI programs?

[Yves-Alexis Perez]

On 28/02/2010 01:32, Ben Finney wrote:
> Josselin Mouette  writes:
> 
>> > Yes, I overall agree with your arguments. However having it in the
>> > policy means we get bug reports about manual pages and have to deal
>> > with them, while they are not the primary source of documentation for
>> > command-line options.
> If manpages were useful only for documenting command-line options, this
> would be a valid point. As has been pointed out, though, manpages for
> programs are useful for much more than that.
> 

But that's why he doesn't propose to forbid manpages for GUI programs,
just to not have them mandatory (well, agreed, it's a “should”). For
programs where there's no point in having a manpage (and only them) he
proposes to drop the “should” requirement, that's all.

That doesn't prevent motivated people/upstream to provide manpages, it
just spares some time for maintainers. I have few cases in Xfce of such
programs (like all the xfce4-*-settings).

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8ea7aa.2060...@debian.org

Re: Bug#545782: imagemagick-dbg: missing README.Debian to explain how programs are used

[Russ Allbery]

Bastien ROUCARIES  writes:

> Any progress on this bug ?

My reading of the general opinion in the discussion (not universal) was
that nothing really needed to be done, since gdb just works out of the box
with the debugging files.  Hence, if one does debugging in the normal way,
everything magically works, leaving nothing particularly needing
explanation in README.Debian.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6i9xn73@windlord.stanford.edu

Re: Mass bug filing for python-apt API transition

[Julian Andres Klode]

Am Mittwoch, den 17.02.2010, 12:09 +0100 schrieb Julian Andres Klode:
> Hi,
> 
> as some of you already know, python-apt received a new
> API (sometimes called 0.8 API). We intent to drop the old API
> for Squeeze+1, and thus ask you to upgrade your packages to
> use the new API.
> 
> Mass bug filing
> ---
> On Friday, I will start reporting bugs on the packages
> in the Debian BTS listed below, with a patch if easily
> possible. All bugs will include the following information:
> 
>   User: de...@lists.debian.org
>   Usertags: python-apt-0-8-api

All bugs have been reported[1]. I wrote patches for 22 packages, and 7
still need patches. I will soon upload version 0.7.93.4 of python-apt
which fixes some more bugs and introduces a new attribute which
update-manager can take advantage of (AcquireItem.partialsize).

I hope to have python-apt migrated in two weeks then.


[1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=de...@lists.debian.org;tag=python-apt-0-8-api

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



signature.asc
Description: This is a digitally signed message part

Re: md5sums files

[Bernd Zeimetz]

Philipp Kern wrote:
> On 2010-03-03, Wouter Verhelst  wrote:
>> This is where I disagree. When a checksum algorithm is compromised (and
>> MD5 *is* compromised), things only ever get worse, not better. Indeed,
>> MD5 preimage attacks are pretty hard *today*. But switching to something
>> more secure in preparation for the day when MD5 will be easily cracked
>> by every script kiddo around is *not* overkill.
> 
> Sure, but to be honest, not even all packages managed to generate md5sums
> 'till now (with some quite core, omnipresent packages missing) so it seems out
> of scope for squeeze.  Maybe squeeze+1.

I think its about time to require to generate checksums for packages and make
all packages which do not do so RC buggy.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8eb3b6.4070...@bzed.de

Re: md5sums files

[Julien Cristau]

On Wed, Mar  3, 2010 at 10:05:11 -0600, Peter Samuelson wrote:

> fundamentally, shipping a md5sums file is really just a tradeoff in
> download size vs. installation speed, not unlike gzip vs. bzip2.  One

Only if you assume that disks never fail and thus files never get
corrupted when the package gets unpacked.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: md5sums files

[Joey Hess]

Osamu Aoki wrote:
> True but debsums can address these issues by system administrator
> touch-ups as documented in manpage using:
> 
>  * /etc/apt/apt.conf.d/90debsums (debsums >= 2.0.7)
>  * debsums_init(8)   (debsums >= 2.0.34 @ 2007)

It's not uncommon to be given an existing system and want to verify
that no files were modified by its creator, and the current lack of
md5sums files for a few packages prevents using debsums to do that.

(The most common case is probably buying a Debian VM from a hosting
company.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: md5sums files

[Peter Samuelson]

[Julien Cristau]
> > fundamentally, shipping a md5sums file is really just a tradeoff in
> > download size vs. installation speed, not unlike gzip vs. bzip2.  One
> 
> Only if you assume that disks never fail and thus files never get
> corrupted when the package gets unpacked.

Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
This could be before, during, or after the deb is unpacked.

Using the packaged foo.md5sums as an internal consistency check of
data.tar.gz itself is interesting, but somewhat unwieldy.  Better would
be to checksum data.tar.gz in its entirety.  But doesn't gzip already
do that?  (Yes, it's only 32 bits, but we aren't trying to detect
intentional tampering, only corruption.  To detect intentional
tampering, you need signed debs, or at least signed Packages.bz2.)
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303200201.gg18...@p12n.org

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 02:02:01PM -0600, Peter Samuelson wrote:
> 
> [Julien Cristau]
> > > fundamentally, shipping a md5sums file is really just a tradeoff in
> > > download size vs. installation speed, not unlike gzip vs. bzip2.  One
> > 
> > Only if you assume that disks never fail and thus files never get
> > corrupted when the package gets unpacked.
> 
> Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> This could be before, during, or after the deb is unpacked.
> 
If you create the hashes at unpack time, you don't catch errors that
happen during unpack.  Why not create them at package build time and
include them? I mean we are talking bytes here for the hashes, not
megabytes. I can't see a download size problem.

> Using the packaged foo.md5sums as an internal consistency check of
> data.tar.gz itself is interesting, but somewhat unwieldy.  Better would
> be to checksum data.tar.gz in its entirety.  But doesn't gzip already
> do that?  (Yes, it's only 32 bits, but we aren't trying to detect
> intentional tampering, only corruption.  
The hash must include the whole package, not just data.tar.gz. 

> To detect intentional
> tampering, you need signed debs, 
Yes, I think that should be the goal.

> or at least signed Packages.bz2.)
You already have this, kind of: the Release file is signed and it contains the
hash of the Packages file, wich in turn contains the hashes for the
packages. The problem here is, that you can only check packages, that
are currently part in some release. If you have an old version lying 
around or a package sent to you by someone, you're out of luck. The
package signature should be part of the package.

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303204038.ge11...@nn.nn

unreliable buildds for non-free

[Joachim Reichel]

Hi,

often my non-free package does not make the transition to testing
because it is missing builds for some architectures. The buildds of
these architectures are unreliable in the sense that sometimes they
build the package, sometime they don't (try to build it). Therefore, the
 package does not migrate to testing due to out-of-date versions for
these architectures.

What is the recommended procedure to deal with this? Last time I asked
the release team to remove the offending architecture from testing.
Should I simply do that for (almost) every upload?

For the package in question (cgal) I am not aware of any users on
architectures except amd64, i386, and alpha.

Is it acceptable to add such non-free packages to Packages-arch-specific
(in general, and in this particular case)?

(Yes, I'm aware of the status of non-free and the status of buildds for
non-free. I just want to know how to handle the situation.)

Joachim


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8ecac6.5010...@gmx.de

Re: md5sums files

[Frank Lin PIAT]

On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > Or is it useful to be able to say "if it doesn't check out, it's
> > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> > think so.
> 
> I don't understand why you say this.  Cryptographic attacks on MD5 aren't
> going to happen as a result of random file corruption.  The MD5 checksums
> are still very effective at finding file corruption or modification from
> what's in the Debian package unless that modification was done by a
> sophisticated attacker (MD5 preimage attacks are still not exactly easy).
> Detecting compromises is useful, but only a small part of what the MD5
> checksums are useful for.  I'd more frequently use them to detect
> well-intentioned but misguided meddling by a local sysadmin.
> 
> I certainly don't object to replacing them with SHA1 hashes, although
> signed deb packages would still be my preferred solution to this problem.

Signed debs may introduce a fake sense of security (Only apt repository
provide security updates). By signing packages, user may assume that a
package is safe when it isn't.

Debian is 15/20 years ahead of commercial operating system on that
point.

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267649891.8266.233.ca...@solid.paris.klabs.be

Re: md5sums files

[Frank Lin PIAT]

On Wed, 2010-03-03 at 11:37 +, Philipp Kern wrote:
> On 2010-03-03, Wouter Verhelst  wrote:
> > This is where I disagree. When a checksum algorithm is compromised (and
> > MD5 *is* compromised), things only ever get worse, not better. Indeed,
> > MD5 preimage attacks are pretty hard *today*. But switching to something
> > more secure in preparation for the day when MD5 will be easily cracked
> > by every script kiddo around is *not* overkill.
> 
> Sure, but to be honest, not even all packages managed to generate md5sums
> 'till now (with some quite core, omnipresent packages missing) so it seems out
> of scope for squeeze.  Maybe squeeze+1.

What about a transitional dh_md5sums that would produce md5sum AND
invoke dh_sha ?

Franklin




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267650344.8266.262.ca...@solid.paris.klabs.be

Debian installer level 1 - danish translation

[Anders Jenbo]

Hi i was handed "Debian installer level 1" to translate, I completed it
back in 6 of December, 2009. but i have not been able to get in contact
with the person who has the danish commit privileges for Debian since
then.

the following is to emails, related to this issue.

the link that is suposed to explain how to commit has been 404'ed ever
since i first got this email.

Sincerly
-Anders

tir, 24 nov 2009 kl. 19:08 +0100, wrote Christian Perrier: 
> Hi,
> 
> This mail is sent to all people who contributed to the last version of the
> Debian Installer "sublevel 1" translations, for the installation software of
> the Debian distribution (which is also used in the Ubuntu installer).
> 
> Debian Installer is constantly evolving and we're still quite far away from
> the planned freeze of the entire Debian distribution (which should happen in
> March 2010). Also, even though a release of Debian Installer is about to
> come soon, we're not planning a fully formalized l10n update process yet.
> 
> Still, several translations had no single update since Debian Lenny was
> released, back in February 2009 (with a release of Debian Installer in
> January 2009).
> 
> So, as Debian Installer l10n corodinator, I'd like to ask you to consider
> updating Debian Installer translations. The most important file, the
> "sublevel 1" file, is attached to this mail.
> 
> Most of you know well about the D-I l10n process, so you'll know how to get
> your hands on the l10n material and how to commit it back. If not,
> http://d-i.debian.org/doc/l10n might be useful for you.
> 
> Some of you were "just" people who volunteered to complete their language
> for the last release of Debian and never mentioned they would commit
> themselves to further updates. Still, I'd like to ask you if you could
> consider doing such update again.
> 
> Some others were just people who once sent a sometimes partial translation
> and never, or vera rarely, followed up on it. Even in such case, please
> consider doing an update...even a minimal one would be appreciated.
> 
> This mailo doesn't give you any deadline...as there is none yet. I however
> needed to send a first "prod" round in order to have a rough idea of what we
> can expect during the general free when it's time to release.
> 
> In any case, thanks for your attentionand good luck for your updates! :-)
> 
> 
> Thanks in advance,
> 


man, 21 sep 2009 kl. 13:36 +0200, wrote Mads Bille Lundby: 
> Hi Christian,
> 
> I have a bunch of updated Danish debian-installer translations, that I
> did in the spring (attachment).
> 
>  I translated the Debian branch og D-i first, hoping that someone
> would pick up my messages on debian-l10n-dan...@lists.debian.org.
> Nobody did. My primary goal was to get a fully translated Ubuntu
> installer. After committing the Debian translations as "Published
> upload" on Launchpad, I subsequently did the remaining Ubuntu Specific
> strings.
> 
> My translations have been proofread in the Danish Translator Group and
> are of fairly high quality, so I'd like to have them committed into
> Debian upstream before I do any further work on the debian-installer.
> 
>  I've noticed that you regularly send out notices regarding incomplete
> translations and such to l10n-dan...@lists.debian.org (which seems
> quite abandoned right now). Maybe you could send the messages cc to
> da...@dansk-gruppen.dk (where KDE, Gnome, Ubuntu, Fedora,
> Mandriva,Xfce etc. hangs out).
> 
> Please contact Keld Simonsen k...@dansk-gruppen.dk to be whitelisted
> as an approved sender/subscriber on da...@dansk-gruppen.dk.
> 
> We should also discuss (internally in dansk-gruppen) who should be
> granted commit priveleges to Debian. From what I can see, Claus
> Hindsgaul has not been active in the Danish Translator Community.
> Could you please inform me, if anyone else has "Danish" commit
> priveleges.
> 
> Cheers,
> 
> Mads Lundby



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267649356.2212.32.ca...@ubuntu.ubuntu-domain

Re: md5sums files

[Michael Gilbert]

On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote:
> On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote:
> > Wouter Verhelst  writes:
> > 
> > > Or is it useful to be able to say "if it doesn't check out, it's
> > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> > > think so.
> > 
> > I don't understand why you say this.  Cryptographic attacks on MD5 aren't
> > going to happen as a result of random file corruption.  The MD5 checksums
> > are still very effective at finding file corruption or modification from
> > what's in the Debian package unless that modification was done by a
> > sophisticated attacker (MD5 preimage attacks are still not exactly easy).
> > Detecting compromises is useful, but only a small part of what the MD5
> > checksums are useful for.  I'd more frequently use them to detect
> > well-intentioned but misguided meddling by a local sysadmin.
> > 
> > I certainly don't object to replacing them with SHA1 hashes, although
> > signed deb packages would still be my preferred solution to this problem.
> 
> Signed debs may introduce a fake sense of security (Only apt repository
> provide security updates). By signing packages, user may assume that a
> package is safe when it isn't.

it should actually be possible to do this securely.  dpkg could be
made to work like apt where it only blindly trusts packages signed
by keys in /etc/apt/trusted.gpg.  the downfall is that there is nothing
stopping the user from adding additional (potentially less than
trustworthy keys), but that isn't really solvable without destroying
freedom, and it isn't any different from the current state for apt.

mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100303162036.dbf12e05.michael.s.gilb...@gmail.com

Re: md5sums files

[Stefano Zacchiroli]

On Wed, Mar 03, 2010 at 08:08:38PM +0100, Bernd Zeimetz wrote:
> I think its about time to require to generate checksums for packages
> and make all packages which do not do so RC buggy.

Well, RC buggy is probably a tad excessive for this release, considering
that we are (I hope :)) close to a freeze. But I agree with the
principle, actually I've been surprised *positively* by the numbers
reported by Wouter and by those I've found on my laptop:

  z...@usha:/var/lib/dpkg/info$ dpkg -l |grep ^ii |wc -l
  2629
  z...@usha:/var/lib/dpkg/info$ ls *md5sums|wc -l
  2603
  z...@usha:/var/lib/dpkg/info$ 

Almost all packages (I've installed) ship md5sums, while the situation
was almost reverted a few releases ago.

I'm curious about what contributed to this positive change (dh7 and/or
CDBS invoking dh_md5sums by default?), any idea?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: md5sums files

[Iustin Pop]

On Wed, Mar 03, 2010 at 08:34:27AM +, Philipp Kern wrote:
> On 2010-03-03, Neil Williams  wrote:
> > Changing to SHA won't help. I'm for ditching all md5sums from packages.
> > It's not a lot of disc space gained but it does give a false sense of
> > security or 'insurance' if you want to avoid the more formal meaning of
> > 'security'.
> 
> Please don't.  It's not about security.  It's about being able to detect
> corruption.  Also it is very helpful when recovering from ext4 root FS
> corruption after a sudden power loss.  Sure, you cannot guarantee that
> the md5 store isn't corrupted too but if it isn't then debsums is
> helpful.

Very much agreed. Please do not remove the md5sums - even better, I'm
all for requiring md5sums (the cost to do so is, I think, insignificant)
because they are very helpful for the above purpose.

iustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303212646.gb9...@teal.hq.k1024.org

Re: md5sums files

[Russ Allbery]

Stefano Zacchiroli  writes:

> I'm curious about what contributed to this positive change (dh7 and/or
> CDBS invoking dh_md5sums by default?), any idea?

We added a Lintian tag warning about not having md5sums in that time
frame, I think.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tysxt6p3@windlord.stanford.edu

Re: unreliable buildds for non-free

[Philipp Kern]

On 2010-03-03, Joachim Reichel  wrote:
> What is the recommended procedure to deal with this? Last time I asked
> the release team to remove the offending architecture from testing.
> Should I simply do that for (almost) every upload?

>From now you should only get buildd uploads for builders that still work,
it should not get less anymore.  I.e. if there's something missing now,
remove it and it will get back when we're back in business.

> Is it acceptable to add such non-free packages to Packages-arch-specific
> (in general, and in this particular case)?

In general: no.  If it gets too much of a pain we can do it temporarily.

I guess we'll get there wrt support of non-free at the end of this month,
at least I hope so.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhotmf7.4u5.tr...@kelgar.0x539.de

Re: Removing the manpage requirement for GUI programs?

[Ben Finney]

Yves-Alexis Perez  writes:

> On 28/02/2010 01:32, Ben Finney wrote:
> > If manpages were useful only for documenting command-line options,
> > this would be a valid point. As has been pointed out, though,
> > manpages for programs are useful for much more than that.
>
> But that's why he doesn't propose to forbid manpages for GUI programs,
> just to not have them mandatory (well, agreed, it's a “should”). For
> programs where there's no point in having a manpage (and only them) he
> proposes to drop the “should” requirement, that's all.

It's already been pointed out that good manpages are plenty useful for
those programs in the proposed exclusion class. The “should” applies
equally well to those programs too.

Sure, some programs don't have good manpages. But that's because the
manpages are not well maintained; it's not because the program belongs
to some special class that makes manpages useless.

-- 
 \ “Try to become not a man of success, but try rather to become a |
  `\   man of value.” —Albert Einstein |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxypukim@benfinney.id.au

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Luis R. Rodriguez]

On Mon, Mar 1, 2010 at 8:39 PM, Paul Wise  wrote:
> On Tue, 2010-03-02 at 04:44 +0200, Faidon Liambotis wrote:
>> Luis R. Rodriguez wrote:
>> > Can you guys upstream a package into Debian with a gitweb URL reference?
>> If I'm understanding the question correctly, yes. We have Vcs-$VCS (i.e.
>> Vcs-Git) and Vcs-Browser pseudo-headers. Both are optional.
>
> The Vcs-* fields are for the Debian package VCS.
>
> There is an emerging project to add upstream metadata to Debian source
> packages:
>
> http://wiki.debian.org/UpstreamMetadata
>
>> I agree with Kel here, git2cl et al are unimportant details.
>
> Indeed, that is why the relevant lintian warning is marked pedantic.
> Personally I think this part of Debian policy needs a review, I don't
> have the time or energy to bring it up on debian-policy though.
>
>> Kel, mail me in private when you have something ready for review &
>> upload, as usual.
>
> Check this thread:
>
> http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2010-March/thread.html#2541
>
> He already created almost perfect packages that are pretty-much ready to
> be uploaded, just a couple of minor issues.

BTW -- while we're on the topic of 2.6.32 and the next Debian release,
and 802.11, do you guys ship iw by default yet? If not I highly
encourage it. It should be shipped just as iwconfig is shipped. iw is
the replacement for iwconfig, it uses the new nl80211 and nl80211 is
used by all cfg80211 and mac80211 drivers. All new upstream drivers
have to be cfg80211 based (or mac80211) so hence why I recommend to
just ship iw by default today.

  Luis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/43e72e891003031416m5572e171j8c7978b77b278...@mail.gmail.com

How KDE uses Htdig

[Mats Erik Andersson]

Dear Developers,

I am having a go at preparing a QA upload for the package Htdig,
but I need some complimentary information before I can submit this
suggestion to mentors.debian.net.

It was my work on an RC-bug that lead to the most recent NMU-upload
for Htdig. At the moment, my new contribution would solve a bug count
in excess of ten for the orphaned package Htdig.

Let me state immediately: As I am no regular subscriber to this particular
list, please send me any answer using a CC entry.

My present worry has to do with the fact that KDE has a dependency on Htdig,
and I do not use KDE, nor do I use Gnome, so therefore I _do_ need some
complimentary information on the matter.

An inherent problem with the present cron job for Htdig, is that it calls
'/usr/bin/rundig', which in turn executes '/usr/bin/htdig -i $options'.
This switch '-i' is the issue of #435242 and relatives, since it enforces
a complete recomputation of the database from scratch each day.

I intend this daily rebuilding to be configurable in the future packaging,
but since it is not clear to me if KDE makes use of 'rundig' iself, or if
only the compiled executables like htdig, htfuzzy, htdump, htmerge, etcetera,
are in fact the tools of choice for the KDE infrastructure.

Could someone please check this for me, in order that I do not risk
the introduction of new implicit bugs, when resolving the handful
reported bugs as well as the few shortcomings I have discovered myself.


With the intent of restoring Htdig to reliability I will be
grateful for all replies,

-- 
Mats Erik Andersson, fil. dr


Abbonerar på: debian-mentors, debian-devel-games, debian-perl, debian-ipv6


signature.asc
Description: Digital signature

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 04:20:36PM -0500, Michael Gilbert wrote:
> On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote:
> > Signed debs may introduce a fake sense of security (Only apt repository
> > provide security updates). By signing packages, user may assume that a
> > package is safe when it isn't.
> 
> it should actually be possible to do this securely.  dpkg could be
> made to work like apt where it only blindly trusts packages signed
> by keys in /etc/apt/trusted.gpg.  the downfall is that there is nothing
> stopping the user from adding additional (potentially less than
> trustworthy keys), but that isn't really solvable without destroying
> freedom, and it isn't any different from the current state for apt.

Completely agreed. Also, because playing around is always more fun than
just talking, I've attached a script that signs/verifies binary
packages. Dpkg doesn't seem to mind the extra files.

This script signs each file in the package individually, but it could 
also concatenate them all alphabetically and create just one signature.

Cheers,
harry
#!/bin/sh

usage() {
cat<
Sign or verify Debian packages

  -s  sign
  -v  verify

EOF
}

sign() {
echo "signing ${DEB}:${FILE}"
ar p "${DEB}" "${FILE}" | gpg --detach-sign --output "${SIG}" - && \
ar r "${DEB}" "${SIG}"
}

verify() {
echo "verifying signature of ${DEB}:${FILE}"
ar p "${DEB}" "${FILE}.sig" > "${SIG}" && \
ar p "${DEB}" "${FILE}" | gpg --verify "${SIG}" -
}

[ $# -eq 2 ] || { usage >&2; exit 1; }

DEB="$2"

case "$1" in
-s) OP="sign";;
-v) OP="verify";;
*)  usage >&2; exit 1;;
esac

[ -f "${DEB}" ] || { printf "%s\n" "${DEB} not found" >&2; exit 1; }

TMPDIR=`mktemp -d --tmpdir debsign.XX` 

ar t "${DEB}" | while read FILE; do
[ "${FILE##*.}" != "sig" ] || continue
SIG="${TMPDIR}/${FILE}.sig"
${OP} || exit 1
done

RC=$?

rm "${TMPDIR}"/* 2>/dev/null
rmdir "${TMPDIR}" 2>/dev/null

if [ ${RC} -eq 0 ]; then
echo "OK"
else 
echo "Failed"
fi

return ${RC}

Re: md5sums files

[Russ Allbery]

Harald Braumann  writes:

> Completely agreed. Also, because playing around is always more fun than
> just talking, I've attached a script that signs/verifies binary
> packages. Dpkg doesn't seem to mind the extra files.

> This script signs each file in the package individually, but it could
> also concatenate them all alphabetically and create just one signature.

See debsigs.

There have been previous discussions on debian-devel about this.  I
believe DAK does not allow packages signed using debsigs to be uploaded.
I'm not sure if that's out of objection to the entire concept, or whether
there are just technical issues that need to be resolved first.  (I
probably would know if I had a better memory for the previous discussion,
but unfortunately I appear to have recycled those brain cells.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tysxhubn@windlord.stanford.edu

Re: md5sums files

[Peter Samuelson]

[Harald Braumann]
> > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> > This could be before, during, or after the deb is unpacked.

> If you create the hashes at unpack time, you don't catch errors that
> happen during unpack.

You mean errors reading the data.tar.gz file?  That is what the gzip
checksum is for, as I said later in my email.

> > Using the packaged foo.md5sums as an internal consistency check of
> > data.tar.gz itself is interesting, but somewhat unwieldy.  Better would
> > be to checksum data.tar.gz in its entirety.  But doesn't gzip already
> > do that?  (Yes, it's only 32 bits, but we aren't trying to detect
> > intentional tampering, only corruption.  
> The hash must include the whole package, not just data.tar.gz. 

Please don't hijack my little thread here.  I'm talking about whether
there are any disadvantages to generating foo.md5sums at unpack time,
other than the obvious one (CPU usage).

Signed debs and signed repositories are an entirely separate
discussion.  md5sums files don't even pretend to solve the same
problems.  They solve other problems.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303234126.gh18...@p12n.org

Bug#572400: ITP: libheimdal-kadm5-perl -- Perl module to administer a Heimdal Kerberos KDC

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery 

* Package name: libheimdal-kadm5-perl
  Version : 0.08
  Upstream Author : Leif Johansson 
* URL : http://search.cpan.org/dist/Heimdal-Kadm5/
* License : BSD (3-clause)
  Programming Lang: Perl/C
  Description : Perl module to administer a Heimdal Kerberos KDC

Heimdal::Kadm5 is a Perl module that wraps the Heimdal libkadm5clnt
library and allows administration of a Heimdal KDC inside Perl programs.
It mimics the commands that would normally be sent to the server with
the kadmin command.  Principal creation, deletion, modification, and
searching and extraction of keytabs are supported.

This module is equivalent to Authen::Krb5::Admin except for a Heimdal
KDC instead of an MIT Kerberos KDC.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100303233854.17404.10759.report...@windlord.stanford.edu

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Peter Samuelson]

[Luis R. Rodriguez]
> BTW -- while we're on the topic of 2.6.32 and the next Debian
> release, and 802.11, do you guys ship iw by default yet?

It's available (version 0.9.14), but not shipped by default.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100303235033.gi18...@p12n.org

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 03:14:04PM -0800, Russ Allbery wrote:
> Harald Braumann  writes:
> 
> > Completely agreed. Also, because playing around is always more fun than
> > just talking, I've attached a script that signs/verifies binary
> > packages. Dpkg doesn't seem to mind the extra files.
> 
> > This script signs each file in the package individually, but it could
> > also concatenate them all alphabetically and create just one signature.
> 
> See debsigs.
Ah, thanks, good to know.

> There have been previous discussions on debian-devel about this.  I
> believe DAK does not allow packages signed using debsigs to be uploaded.
> I'm not sure if that's out of objection to the entire concept, or whether
> there are just technical issues that need to be resolved first.  (I
> probably would know if I had a better memory for the previous discussion,
> but unfortunately I appear to have recycled those brain cells.)

Maybe this [0]?

Also, it seems, that people have `discussed' it, and that there was
experimental support in dpkg for it [1]. The proposal, that came out of
this discussion is outlined in [2]. This was in 2000 ...

I haven't found any specific reasons why it was never implemented. I guess
the reason is just that it's hard to do. Not the technical side, but
defining the processes.

harry

[0] http://lists.debian.org/debian-devel/2002/03/msg01484.html
[1] http://lists.debian.org/debian-dpkg/2000/07/msg1.html
[2] http://lists.debian.org/debian-dpkg/2000/07/msg00044.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100304000655.ga16...@nn.nn

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote:
> 
> [Harald Braumann]
> > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> > > This could be before, during, or after the deb is unpacked.
> 
> > If you create the hashes at unpack time, you don't catch errors that
> > happen during unpack.
> 
> You mean errors reading the data.tar.gz file?  That is what the gzip
> checksum is for, as I said later in my email.

Errors writing a file. 

If there should be support in the future for signing hash files, then
creating them would have to be done at package creation time anyway. 

Also, I think, that it is in general better to have as much complexity
as possible in the package builder and make the client tools as dumb
as possible.

harry





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100304002053.gb16...@nn.nn

Re: Removing the manpage requirement for GUI programs?

[Luca Niccoli]

2010/2/27 Josselin Mouette :

> GUI applications usually take only a few simple command-line options,
> and more importantly, when you use a modern development framework, these
> options will always be documented correctly with the --help switch.

Manuals are not only for documenting command line switches, they
should actually explain how to use a program.
I found the lack of good man pages one of the most annoying and
widespread problems of OSS.
Unfortunately, this gets more and more common with GUIs, as if a
graphical program could always be self-explanatory.
I completely agree that a debian maintainer can't take the burden to
write every man page upstream has not written, but that doesn't change
the fact that a missing, outdated or incomplete manual is a bug - to
be forwarded upstream if possible.
As has already been noted, the policy says there SHOULD be a manual
page, so a missing one doesn't make a package RC buggy.
On a side note, I find the habit of replacing the manual with on-line
html documentation terrible - we don't live in an always on-line world
yet.

> Manual pages, OTOH, are not maintained properly by upstream developers.

Sadly you are right.
Please try to educate upstream whenever possible.
Writing good documentation has never been fun, but it dramatically
improves the usefulness of a program.
Cheers,

Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4e9568871003031622t2861165eh4c54b63378197...@mail.gmail.com

Re: How KDE uses Htdig

[Sune Vuorela]

On 2010-03-03, Mats Erik Andersson  wrote:
> Dear Developers,
> My present worry has to do with the fact that KDE has a dependency on Htdig,
> and I do not use KDE, nor do I use Gnome, so therefore I _do_ need some
> complimentary information on the matter.
>
> I intend this daily rebuilding to be configurable in the future packaging,
> but since it is not clear to me if KDE makes use of 'rundig' iself, or if
> only the compiled executables like htdig, htfuzzy, htdump, htmerge, etceter=
> a,
> are in fact the tools of choice for the KDE infrastructure.

Hi

KDE does not rely on any 'system services' regardnig htdig. It is used
to index the manuals in the kde helpcenter in order to make them
searchable.

If you want to test it, apt-get install khelpcenter4 and try to index
documentation.

(In the left pane, select the Search Options tab. first time, it should
offer to build indexes. Later on, you can manually reindex by pressing
the 'Build Search Index' button in that tab)

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhotvog.nfa.nos...@sshway.ssh.pusling.com

Re: Removing the manpage requirement for GUI programs?

[Stanislav Maslovski]

On Wed, Mar 03, 2010 at 07:17:14PM +0100, Yves-Alexis Perez wrote:
> On 28/02/2010 01:32, Ben Finney wrote:
> > Josselin Mouette  writes:
> > 
> >> > Yes, I overall agree with your arguments. However having it in the
> >> > policy means we get bug reports about manual pages and have to deal
> >> > with them, while they are not the primary source of documentation for
> >> > command-line options.
> > If manpages were useful only for documenting command-line options, this
> > would be a valid point. As has been pointed out, though, manpages for
> > programs are useful for much more than that.
> > 
> 
> But that's why he doesn't propose to forbid manpages for GUI programs,
> just to not have them mandatory (well, agreed, it's a “should”). For
> programs where there's no point in having a manpage (and only them) he
> proposes to drop the “should” requirement, that's all.
> 
> That doesn't prevent motivated people/upstream to provide manpages, it
> just spares some time for maintainers. I have few cases in Xfce of such
> programs (like all the xfce4-*-settings).

My two cents:

I have seen manpages in Debian that basically claim that "This program
does not have a useful manpage, for the information look into
bla-bla-bla..." I think that even having such a man page is better
than not having one at all. Just because it clearly indicates where to
look for additional information. In fact, a group of related programs
that have information about them shared in a common place or have the
same means to get this information (like --help command line option)
could symlink to a single man file. 

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100304004148.ga22...@kaiba.homelan

Re: md5sums files

[Peter Samuelson]

[Harald Braumann]
> On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote:
> > 
> > [Harald Braumann]
> > > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> > > > This could be before, during, or after the deb is unpacked.
> > 
> > > If you create the hashes at unpack time, you don't catch errors that
> > > happen during unpack.
> > 
> > You mean errors reading the data.tar.gz file?  That is what the gzip
> > checksum is for, as I said later in my email.
> 
> Errors writing a file. 

Did you read the text you quoted?

Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.

(By "SMOP", I meant "simple matter of programming".)

This has nothing to do with writing a file, except writing
/var/lib/dpkg/info/foo.md5sums, which is unavoidable.

Peter


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100304005028.gj18...@p12n.org

Re: md5sums files

[Harald Braumann]

On Wed, Mar 03, 2010 at 06:50:28PM -0600, Peter Samuelson wrote:
> 
> [Harald Braumann]
> > On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote:
> > > 
> > > [Harald Braumann]
> > > > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> > > > > This could be before, during, or after the deb is unpacked.
> > > 
> > > > If you create the hashes at unpack time, you don't catch errors that
> > > > happen during unpack.
> > > 
> > > You mean errors reading the data.tar.gz file?  That is what the gzip
> > > checksum is for, as I said later in my email.
> > 
> > Errors writing a file. 
> 
> Did you read the text you quoted?
> 
> Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> 
> (By "SMOP", I meant "simple matter of programming".)
> 
> This has nothing to do with writing a file, except writing
> /var/lib/dpkg/info/foo.md5sums, which is unavoidable.

I think I was finally able to decipher your message. But my other points still 
hold. And while it is just a matter of programming, simple or not, it already 
exists in debhelper. So doing it at build time is SMOAOLTDR, by which I mean
"simply a matter of adding one line to debian/rules".

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100304011155.gd16...@nn.nn

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Luis R. Rodriguez]

On Wed, Mar 3, 2010 at 3:50 PM, Peter Samuelson  wrote:
>
> [Luis R. Rodriguez]
>> BTW -- while we're on the topic of 2.6.32 and the next Debian
>> release, and 802.11, do you guys ship iw by default yet?
>
> It's available (version 0.9.14), but not shipped by default.

Can it?

  Luis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/43e72e891003031751uf0965a0o427708d86976a...@mail.gmail.com

Re: md5sums files

[James Vega]

On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote:
> I think I was finally able to decipher your message. But my other points 
> still 
> hold. And while it is just a matter of programming, simple or not, it already 
> exists in debhelper. So doing it at build time is SMOAOLTDR, by which I mean
> "simply a matter of adding one line to debian/rules".

You make the mistake of assuming everyone use debhelper.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: md5sums files

[Russ Allbery]

James Vega  writes:
> On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote:

>> I think I was finally able to decipher your message. But my other
>> points still hold. And while it is just a matter of programming, simple
>> or not, it already exists in debhelper. So doing it at build time is
>> SMOAOLTDR, by which I mean "simply a matter of adding one line to
>> debian/rules".

> You make the mistake of assuming everyone use debhelper.

Yeah, but:

@set -ex; \
cd debian/tmp; \
find . -path "./DEBIAN" -prune -o -type f -printf '%P\0' \
   | xargs -r0 md5sum > DEBIAN/md5sums

(from debian-policy's rules file).  dh_md5sums isn't particularly
complicated, although admittedly it deals with a few more cases for you,
such as multiple packages.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vg0g6ru@windlord.stanford.edu

Depends: libapt-pkg-libc ... which is a virtual package

[jidanni]

It seems for us experimental archive users, most of the year we see e.g.,

The following packages have unmet dependencies:
  aptitude: Depends: libapt-pkg-libc6.9-6-4.8 which is a virtual package.
  python-apt: Depends: libapt-inst-libc6.9-6-1.1 which is a virtual package.
  Depends: libapt-pkg-libc6.9-6-4.8 which is a virtual package.
  libapt-pkg-perl: Depends: libapt-pkg-libc6.9-6-4.8 which is a virtual package.
  libept0: Depends: libapt-pkg-libc6.9-6-4.8 which is a virtual package.

then about every two months the problems go away for two weeks.

It would be nicer if every two months, the problem persisted for only
two weeks. Can't somehow things be more coordinated?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk8giz1t@jidanni.org

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Ben Hutchings]

On Wed, 2010-03-03 at 17:51 -0800, Luis R. Rodriguez wrote:
> On Wed, Mar 3, 2010 at 3:50 PM, Peter Samuelson  wrote:
> >
> > [Luis R. Rodriguez]
> >> BTW -- while we're on the topic of 2.6.32 and the next Debian
> >> release, and 802.11, do you guys ship iw by default yet?
> >
> > It's available (version 0.9.14), but not shipped by default.
> 
> Can it?

Depends on what you mean by 'default'.  I think there's a good case for
including it in the 'laptop' task, but not in the standard system
(desktops and servers generally don't need it).  It should also be
upgraded to 'optional' priority.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Re: Debian installer level 1 - danish translation

[Christian PERRIER]

Quoting Anders Jenbo (and...@jenbo.dk):
> Hi i was handed "Debian installer level 1" to translate, I completed it
> back in 6 of December, 2009. but i have not been able to get in contact
> with the person who has the danish commit privileges for Debian since
> then.
> 
> the following is to emails, related to this issue.
> 
> the link that is suposed to explain how to commit has been 404'ed ever
> since i first got this email.

OK, ACK. We'll sort this out..:-)

hanks for your mail. I'll come back to you later on.



signature.asc
Description: Digital signature