Re: (seemingly) declinging bug report numbers

[Charles Plessy]

Le Fri, Oct 12, 2012 at 11:47:30AM +0300, Riku Voipio a écrit :
> 
> While people want LTS, they still want latest version of various apps
> they use (browser, new gcc and python for some inhouse development, etc),
> as well as support for all the new hardware they buy. Solving these two
> goals at the same time is tricky. We'd like to have the cake and eat it
> too.

There may be some light at the end of the tunnel with two game-changing
developments:

 - The possibility to copy packages between archives with the same interface
   already in use to manage DM permissions. This could be used to allow the
   maintainer of a package in Testing to copy it to Backports.
   (https://lists.debian.org/debian-devel-announce/2012/09/msg8.html)

 - The transfer of a package's regression tests from the build process to
   the "autopkgtest" system.  This would allow to frequently test that packages
   in Backports are working.  (http://dep.debian.net/deps/dep8/)

In my field (command-line bioinformatics), where the build dependencies are
often simple and not too demanding, it think it will be straightforward to
provide up-to-date backports even if the support for Stable is extended of a
few years.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20121013024351.gb30...@falafel.plessy.net

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Michael Gilbert]

On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote:
> On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote:
>> Which is impossible, or at least man-powerwise insurmountable.  There
>> are something like 500 million lines of code in a Debian release.
> I wasn't talking about such an impossible task,... but there speaks
> nothing against relatively easy things,... like securing all of our
> package repository infrastructure by strong algos (as we already did)...
> and trying to prevent higher level attacks, like downgrade attacks.

Do you have evidence of any of those things?  If so, please submit
bugs, and we will look at fixing them.  Otherwise, speculation gets us
nowhere and actually wastes time.

Best wishes,
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/CANTw=MNPfrP=n+92thmy7tsqp8wqrkpexynghif0nhs0zpm...@mail.gmail.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote:
> Which is impossible, or at least man-powerwise insurmountable.  There
> are something like 500 million lines of code in a Debian release.
I wasn't talking about such an impossible task,... but there speaks
nothing against relatively easy things,... like securing all of our
package repository infrastructure by strong algos (as we already did)...
and trying to prevent higher level attacks, like downgrade attacks.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Michael Gilbert]

On Fri, Oct 12, 2012 at 4:31 PM, Christoph Anton Mitterer wrote:
> But it's a general security paradigm, that one shouldn't just focus on
> the attack vectors one can think of... but rather trying to secure
> "everything" ;)

Which is impossible, or at least man-powerwise insurmountable.  There
are something like 500 million lines of code in a Debian release.
Obviously not all code bits have security implications, but the right
flaw in any one link in that chain could lead to security problems.
If we were rigorous, that would 500,000 lines of code to review per
DD.  An impossible and error-prone task.

It's more about identifying mistakes, learning from them, attempting
to track *everything*, and correcting known problems quickly.

Best wishes,
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/CANTw=mp9wqmuuey4-err4jnnrzn1nnpkpscbz5nt1ca4dru...@mail.gmail.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Fri, 2012-10-12 at 13:10 +0200, David Kalnischkies wrote:
> Oh, and there is "Description-md5". I can't imagine a scenario in which it
> would be useful to change the English description of a package for an attack
> (which you want to hide by displaying the translations of the not modified
> version)

I cannot think of any either, well at lest not of anything, for which a
plain collision would be enough,...

But it's a general security paradigm, that one shouldn't just focus on
the attack vectors one can think of... but rather trying to secure
"everything" ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: (seemingly) declinging bug report numbers

[Christoph Anton Mitterer]

On Thu, 2012-10-11 at 13:40 +0200, Stefano Zacchiroli wrote:
> I wonder: did upstream developers start to worry when the number of bugs
> report they received *directly* started to decrease, due to Debian
> distributing their software?
Well but that's a different situation isn't it? I mean Debian typically
doesn't "duplicate" what upstream is doing, but in your example rather
serve as some intermediate layer for bugs, either directly solving them
(and then hopefully push that upstream) or simply forwarding the bugs.

With derivatives, it's not only that (don't know how much of the bugs
e.g. reported at Ubuntu are then forwarded to Debian, if they manage the
respective package themselves)... the really copy and make the same
work...

And I can't quite believe that this doesn't ultimately take users and
manpower away from Debian.

An example is that, especially stuff from the commercial- (or at least
non-open-source-) world seems to drop out Debian from their supported
major distros and replace it by *buntu (given that it must be "better"
for its "commercial support") well at least in my experience.


> In fact, the resulting ecosystem probably
> brings *more* users and bug report to them than before, albeit now they
> are mediated. Looks like the same situation.
I wonder whether the majority of the Debian community sees it like
that... especially the Debian/*buntu relationship.


Guess I'll be in the minority, but I think all that is quite worrying
for Debian's long term future.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

Hey Paul.

On Fri, 2012-10-12 at 20:48 +0800, Paul Wise wrote:
> Sounds like you have a person in the middle hacking your network (or a
> browser bug), it works for me:
*g* guess I somehow deserved that ;) ... and not even SHA-3 would have
protected me from not verifying against Release.asc ^^


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: (seemingly) declinging bug report numbers

[Christoph Anton Mitterer]

On Thu, 2012-10-11 at 21:45 +0200, Simon Josefsson wrote:
> IMHO, supporting an OS release for only 3 years is not long enough.

I think that such very-long-term security support is quite an illusion.

Of course, problems found get then back-ported,... but software changes
so rapidly while usually the quite recent versions are
tested/analysed... so it's questionable whether issues in very old
versions will ever be found (be the good guys), simply because they are
no longer that intensively looked at.

No to speak about all issues that get silently closed, simply because no
one ever notices that there was actually a problem.


So IMHO, the older software gets, the less security support can be
provided. Personally I think the 3 years are fine.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Philipp Kern]

On Fri, Oct 12, 2012 at 09:05:01AM -0600, Wesley J. Landaker wrote:
> On Friday, October 12, 2012 05:10:12 David Kalnischkies wrote:
> > On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
> >  wrote:
> > > algo,... not to mention that newer algos like Keccack are quite fast.
> > I wonder if it is really a good idea to search for a security checksum
> > based on the metric that it can be quickly calculated … but off-topic.
> FWIW, NIST disagrees. Keccack is SHA-3: 
> 

And conspiracy theories are lingering why that is… :)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Lucas Nussbaum]

On 11/10/12 at 22:18 +, Sam Hartman wrote:
> 
> For myself, I'd feel a lot more comfortable with DDs seconding than DMs
> seconding.
> 
> In my mind, when you sign up to be a DM, you're signing up to do a good
> job of maintaining one or more packages.
> 
> In my mind a part of the additional commitment in agreeing to be a DD is
> to think about the broader issues of the project, for example, the
> social implications of your decision, to try and help build Debian as a
> community and team.
> I think that broader view is important when doing something that is
> likely to have social consequences like an ITO.
> 
> So, I would prefer DD seconds to DM seconds.

(Fully agreed.)

Lucas


-- 
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/20121012150840.gc26...@xanadu.blop.info

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Lucas Nussbaum]

On 11/10/12 at 11:27 +0200, Arno Töll wrote:
> Hi,
> 
> On 11.10.2012 07:50, Bart Martens wrote:
> >> - the submitter of the "intent to orphan" bug must Cc 
> >>   debian...@lists.debian.org, and file the bug with severity:serious (this 
> >>   was part of the "criterias" proposal).
> >   |  Anyone can mark a package as orphaned after the following steps have 
> > been
> >   |  completed : Someone submits an "intent to orphan" (ITO) in the bts 
> > with an
> >   |  explanation of why he/she thinks that the package needs a new 
> > maintainer.  
> 
> I don't think "intend to orphan" (ITO) is a good name. First of all, it
> is wrong, because if you file such a bug, you eventually don't want to
> orphan a package, but quite the contrary revive its maintenance.
> Moreover, its name suggests it would be a WNPP bug, which it isn't and
> wouldn't be.

Any ideas of better names?

> *  can we really be sure that random developers flying by, care enough
> to look into a package they may not care about, inspect its situation
> and ack/nack? The whole new mechanism could be bypassed by feedback
> timeout. Frankly, many packages which could be salvaged in future are
> not on of these which draw much attraction.

In the process, most of the burden is put on the one requesting the
orphaning. That person has to build a sufficiently strong case that the
package should be orphaned. I don't expect random DDs to deeply
investigate the package themselves, but rather to check the facts put
forward by the requester and then ACK/NACK. That task is sufficiently
lightweight that I think finding 3 DDs will be easy. Plus, the smell of
blood is likely to attract DDs to look into those cases ;)

> * You cannot require a 3:1 majority without giving a time window to
> raise objections. The way Bart proposed it in his draft, one couldn't
> make sure a 3:1 majority is reached before 75% of *all* developers
> agreed for the opened case. I don't think that's desired or realistic.

Correct, but addressed by Gergely's proposal in
<87r4p58llk.fsf@algernon.balabit>, I think.

> * How would you validate binding votes on a salvage process? You would
> need to require to send signed mails to the list for seconding.
> Otherwise we did not win anything over votes allowed by anyone.

Yes, votes must be signed, and it's the responsibility of the
requester to check the signatures.

Lucas


-- 
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/20121012150726.gb26...@xanadu.blop.info

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Lucas Nussbaum]

On 11/10/12 at 10:21 +0200, Gergely Nagy wrote:
> Lucas Nussbaum  writes:
> 
> > On 11/10/12 at 05:50 +, Bart Martens wrote:
> >>   |  Anyone can mark a package as orphaned after the following steps have 
> >> been
> >>   |  completed : Someone submits an "intent to orphan" (ITO) in the bts 
> >> with an
> >>   |  explanation of why he/she thinks that the package needs a new 
> >> maintainer.  The
> >>   |  explanation should cover aspects like how long there was no visible 
> >> activity,
> >>   |  whether there are NMUs not yet acknowledged, wheter the package 
> >> blocks progress
> >>   |  elsewhere in Debian, release critical bugs, public comments from the 
> >> maintainer
> >>   |  revealing lack of interest in the package, ... etc.  The bug must 
> >> have severity
> >>   |  "serious" and a cc must be sent to the debian-qa mailing list.  
> >> Anyone can
> >>   |  submit this "intent to orphan".  At least three DDs (not counting the 
> >> initial
> >>   |  submitter) second the "intent to orphan" on the same bug report with 
> >> a cc to
> >>   |  the maintainer.  If some DDs send NACKs instead, then a 3/1 majority 
> >> is needed
> >>   |  between ACKers and NACKers.
> >
> >> And the maintainer does not respond within one month after the the third 
> >> second.
> >
> > I'm not sure about this delay. This procedure should be used for
> > uncontroversial cases, where orphaning is obviously the right choice.
> 
> I strongly agree here. A package that's a salvaging candidate has
> already been neglected far too long, requiring another extra month of at
> most NMU-maintainance is counter productive.
> 
> A maintainer has many ways to signal in advance that he/she will be
> unable to answer bug reports or mail for a longer period of time
> (including VAC messages on -private, and/or setting a vacation message
> in LDAP), many of which can and should be checked as soon as the
> salvaging process starts, to make sure there's no accidental overlap.
> 
> With that done, I do not see the point of waiting an extra month. I
> would, however, put a time limit on the NACKs: one week after 3 ACKs or
> 3/1 majority is reached, the decision's done, and further ACKs/NACKs
> won't be counted. That is, we'd have a time limit on everyones ability
> to contribute to the salvaging process, not just a ticking clock for the
> maintainer.

OK

> > Maybe rephrase that into "Before taking action, it could also be a good
> > idea to wait for comments from the maintainer, especially if he/she is
> > otherwise active in Debian."
> 
> I'd rephrase that further, with a s/wait for/seek/, because in my
> opinion, the person wanting to salvage a package should go to great
> lengths to reach the maintainer. Merely waiting when the package is
> obviously neglected sounds like a very passive thing to me.

OK. What is considered "sufficiently seeking for comments" can probably
be decided on a case-by-case basis (i.e., people should not ACK before
the waiting time is considered sufficient by them).

Lucas


-- 
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/20121012150135.ga26...@xanadu.blop.info

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Lucas Nussbaum]

On 11/10/12 at 18:44 +0900, Charles Plessy wrote:
> Le Thu, Oct 11, 2012 at 05:50:51AM +, Bart Martens a écrit :
> > 
> >   |  Anyone can mark a package as orphaned after the following steps have 
> > been
> >   |  completed : Someone submits an "intent to orphan" (ITO) in the bts 
> > with an
> >   |  explanation of why he/she thinks that the package needs a new 
> > maintainer.  The
> >   |  explanation should cover aspects like how long there was no visible 
> > activity,
> >   |  whether there are NMUs not yet acknowledged, wheter the package blocks 
> > progress
> >   |  elsewhere in Debian, release critical bugs, public comments from the 
> > maintainer
> >   |  revealing lack of interest in the package, ... etc.  The bug must have 
> > severity
> >   |  "serious" and a cc must be sent to the debian-qa mailing list.  Anyone 
> > can
> >   |  submit this "intent to orphan".  At least three DDs (not counting the 
> > initial
> >   |  submitter) second the "intent to orphan" on the same bug report with a 
> > cc to
> >   |  the maintainer.  If some DDs send NACKs instead, then a 3/1 majority 
> > is needed
> >   |  between ACKers and NACKers.  And the maintainer does not respond 
> > within one
> >   |  month after the the third second.  During this process anyone is 
> > welcome to add
> >   |  comments on the bug.
> 
> Hi Bart,
> 
> here are some comments.
> 
>  - It would be more straight to the point to submit an "Intend To Salvage" 
> (ITS) and
>focus on such takeovers, because merly orphaning the package does not 
> guarantee
>that it will be actively maintained.

That makes the assumption that the requester will be able to salvage the
package. I would prefer if we stick to the fact: what's it's about is
orphaning the package.

Note that this procedure could also be used as a lightweight replacement
to the MIA procedure, for example if a maintainer has only one package.
In that case, it would make sense to orphan the package without the
promise to salvage it, simply to reflect the fact that the maintainer is
long gone (that way, people using wnpp-alert will identify the package
as being up for adoption).

>  - You may clarify that the bug is to be reported to the package, not to
>   the wnpp pseudo-package.

(ack)

>  - How about requesting that the explanation contains the plans for future 
> work on
>the package ?

See above.

>  - I am not found of the voting procedure, and would rather propose to follow 
> a
>similar process as for the modification of the Policy and the Developers
>Reference, where at least three DDs need to indicate that, in their 
> conclusion,
>a consensus has been reached.  I think that if a package is orphaned with 
> for
>instance a 16:3 majority, it indicates a problem rather than a consensus.  
> Also
>if the maintainer opposes, this shows lack of consensus and a vote can only
>aggravate the situation.

It should be outlined that this procedure is a lightweight process that
describes how it's considered acceptable to orphan package in simple and
obvious situations. I personally would NACK all attempts to "steal"
packages from active maintainers, and I'm quite sure that I would not be
the only one. :-)  We have a procedure (bring the case to the TC) for
those situations, the problem is that it would not scale to bring
all such simple situations to the TC.

Similarly, when discussions show that the situation is not simple and
obvious, I would be inclined to NACK on the basis that the situation is
sufficiently complex to be brought to the TC. (And again, I'm quite sure it
will be easy to find more DDs agreeing with that, than 3X more DDs
willing to go fast).

>  - For response delay, it think that one month after the bug is opened would 
> be
>a good compromise.  It also makes the deadline more predictable, as opposed
>to voting or counting consensus assessments.

(I made my point about delays in another mail, so I'm not replying here)

>We can not use private
>information such as vacation flag of the LDAP database in public bug 
> records,
>so we must assume that the maintainer may not be available.  This said 
> perhaps
>we can request that DDs must not post ITS on pacakges where the maintainer 
> has
>declared being on vacation in the LDAP ?

So, we are talking about a case where a maintainer would have been on
VAC for a long enough time to allow a package to become in such a
terrible state that NMUs are no longer sufficient to maintain its
quality at a reasonable level. In that case, I would not consider it
unreasonable to orphan the package. After all, We should prioritize the
distribution's quality higher than the ownership of packages.

>  - Lastly, how about an expiration date ?  If we all agree on a one-month 
> delay
>for the maintainer's response, we can also use it as an expiration date.  
> If
>within a month there is no reaction of the maintainer, but on the other 
> hand
>the pr

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Charles Plessy]

Le Fri, Oct 12, 2012 at 12:06:11PM +0200, Benjamin Drung a écrit :
> Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise:
> 
> https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/
> 
> The poll will be closed in one week (if enough votes are collected).

Hello everybody,

if the point is to have a package that pulls everything one needs when doing
random work in Debian (as opposed with working specifically in one team where
it is predictable which helpers are used and which are not), then I do not
understand the point of not including *-buildpackage and dh-make, which are
tiny regarding to most other things that mk-builddeps will pull in later.

I think that it is exactly the case where we should not vote.  Unless the
wheight of bzr and dh-make is unbearable to otherwise users of packaging-dev,
even if the majority do not use them, what is the harm recommending them ?
Not to mention that there is no evidence that the people who vote for or
against recommending them are really using packaging-dev...

Cheers,

-- 
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/20121012151034.ga15...@falafel.plessy.net

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Wesley J. Landaker]

On Friday, October 12, 2012 05:10:12 David Kalnischkies wrote:
> On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
> 
>  wrote:
> > algo,... not to mention that newer algos like Keccack are quite fast.
> 
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.

FWIW, NIST disagrees. Keccack is SHA-3: 



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

Re: Popularity of bzr-builddeb and dh-make

[Nikolaus Rath]

Craig Small  writes:
> debhelper has gotten smarter with every release and gradually what
> dh-make has had to do is getting reduced.  I'm not sure we're at the
> point of removing dh-make (it's an open question; I'm really not sure)
> but perhaps we will be there one day.  As it was written to solve a
> problem, if the problem goes then we won't need it.
>
> Steve with his years of packaging experience is not probably a good
> sample of one to base this upon. I'd be curious to see if newer
> packagers use it or not.

I've started packaging two packages about a year ago and first tried it
with dh-make. I found it confusing and not helpful. I don't remember
many details of dh-make, but the gazillions of files that it created
were definitely a contributing factor. I then tried debhelper which made
me much happier and have been using it ever since.

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/87626f7rtx@inspiron.ap.columbia.edu

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Dmitrijs Ledkovs]

On 12 October 2012 13:52, Hideki Yamane  wrote:
> On Fri, 12 Oct 2012 14:46:41 +0200
> Jelmer Vernooij  wrote:
>> The workflow doesn't have to involve Launchpad either - I'm not using
>> Launchpad at all for my Debian packages. Just because the majority of
>> Bazaar users host their branches on Launchpad, doesn't mean that a
>> Bazaar workflow has to involve Launchpad.
>
>  Okay. I'm wrong.
>
>  BTW, most people uses svn or git, what is prefer you to use bazaar?
>  I'm curious.
>

well the fact that it works nice out of the box and has nice command
line syntax.

pristine tarball is on by default.
auto detects: native/non-native and full source vs debian/ dir only
packaging by default
auto fetches tarballs: from the pristine tar, from apt, from servers
with get-orig-tarball, with uscan
builds packages in a sane way, even if you have uncommited changes:
bzr bd (for debuild), bzr bd -S (for src package only)
Simple to make it split-mode: e.g. if you are both upstream and
packager, you can do $ bzr bd --split, which will create original
tarball sans debian dir and build proper non-native package (this is
very hard to do with other tools)
bzr-bd supports merging packages really well when you fork sid &
experimental and what to keep both forks in sync, or finally fold
experimental into sid, without loosing changelogs.
(BTW I hate how some maintainers do not keep NMU changelog entries)
bzr-bd can deal with quilt patches sensibly by auto applying &
removing them depending on your preference, the default is sane as
well.

also great support on ubuntu-udd mailing list and ubuntu-motu irc
channels using it for most core packages in ubuntu helps as well.

The list goes on =)

With svn/git/hg/mnt-buildpackage I have yet to see all of these little
features work so well out of the box with no or little configuration.

I wish hg-queues would be better integrated into hg-buildpackage, or
bzr-bd had pipes/looms support for top class quilt patch management.
But none other tools get it right either.

Regards,

Dmitrijs.


-- 
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/CANBHLUicU2BJYe7x4HNQQPwT4Q1=24txl8pn_byqnuiov6n...@mail.gmail.com

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Hideki Yamane]

On Fri, 12 Oct 2012 14:46:41 +0200
Jelmer Vernooij  wrote:
> The workflow doesn't have to involve Launchpad either - I'm not using
> Launchpad at all for my Debian packages. Just because the majority of
> Bazaar users host their branches on Launchpad, doesn't mean that a
> Bazaar workflow has to involve Launchpad. 

 Okay. I'm wrong.

 BTW, most people uses svn or git, what is prefer you to use bazaar?
 I'm curious.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20121012215213.f9ff9b7bb0c6da2f4e410...@debian.or.jp

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Paul Wise]

On Fri, Oct 12, 2012 at 7:49 PM, Christoph Anton Mitterer
 wrote:

> Then what's this:
> ftp://ftp.de.debian.org/debian/dists/sid/Release

Sounds like you have a person in the middle hacking your network (or a
browser bug), it works for me:

pabs@chianamo ~ $ GET ftp://ftp.de.debian.org/debian/dists/sid/Release
| grep ^SHA
SHA1:
SHA256:

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6evoavm7yarnovztopg5ussf2bnwdjnoazoj8rdd+a...@mail.gmail.com

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Jelmer Vernooij]

On Fri, 2012-10-12 at 21:40 +0900, Hideki Yamane wrote:
> On Fri, 12 Oct 2012 14:22:06 +0200
> Benjamin Drung  wrote:
> > How does bzr-builddeb depend on Launchpad? bzr is integrated into
> > Launchpad, but you can use bzr without Launchpad as every other DVCS.
> 
>  Just because I don't imagine use bzr without LP ;)
>  Yes, it can be used as you've pointed out, but using VCS is not only 
>  tools but also includes workflow, I think. So I said it relies on LP.
The workflow doesn't have to involve Launchpad either - I'm not using
Launchpad at all for my Debian packages. Just because the majority of
Bazaar users host their branches on Launchpad, doesn't mean that a
Bazaar workflow has to involve Launchpad. 

Similarly, just because a lot of Git users host their branches on Github
doesn't mean that Git is unusable without Github.

Cheers,

Jelmer


-- 
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/1350046001.7083.27.camel@gwenhwyvar

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Hideki Yamane]

On Fri, 12 Oct 2012 14:22:06 +0200
Benjamin Drung  wrote:
> How does bzr-builddeb depend on Launchpad? bzr is integrated into
> Launchpad, but you can use bzr without Launchpad as every other DVCS.

 Just because I don't imagine use bzr without LP ;)
 Yes, it can be used as you've pointed out, but using VCS is not only 
 tools but also includes workflow, I think. So I said it relies on LP.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20121012214007.bb9829657eb41d4ca5aa6...@debian.or.jp

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Jelmer Vernooij]

On Fri, 2012-10-12 at 21:13 +0900, Hideki Yamane wrote:
> On Fri, 12 Oct 2012 12:06:11 +0200
> Benjamin Drung  wrote:
> > I have setup a poll for it:
> > https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/
> 
>  Thanks! :)  voted.
> 
>  My opinion is as BTSed,
>   - dh-make is still usable for 1st step. Maybe experienced/skilled developer
> don't need it (but needed it at least for me ;)
> 
>   - bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed
> Development, as Ubuntu packaging guide says) way, but now it heavily 
> relies on Launchpad in my point of view. And, packaging-dev can specify
> vendor-specific Recommends/Suggest in its rules, then use it for Ubuntu
> is meaningful.
> 
> (Well, LP is quite nice and Debian should consider to introduce its good
>  point (user friendly web interface, etc), but I don't want to depend on
>  it, sorry).
bzr-builddeb is perfectly well usable without Launchpad; it doesn't
depend on it. I've been using it with bzr.debian.org for a long time. 

There are two commands that have some Launchpad-specific integration,
but that integration is completely optional and those commands are still
perfectly usable without Launchpad. There is also no hard dependency on
python-launchpadlib.

Cheers,

Jelmer


-- 
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/1350044879.7083.18.camel@gwenhwyvar

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Dmitrijs Ledkovs]

On 12 October 2012 13:03, Adam D. Barratt  wrote:
> I'm struggling to see what point you believe you're making here.
>

The point he was trying to make that he either caught a mirror during
update, or his connection was flaky, as he didn't fetch the complete
file, nor verify it's gpg signature.

Regards,

Dmitrijs.


-- 
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/canbhlugp6ep6e+d0obqfdx0n8h8oezopbjr05jnpm07jqbr...@mail.gmail.com

Re: Popularity of bzr-builddeb and dh-make

[Andrej N. Gritsenko]

Hello!

Игорь Пашев has written on Friday, 12 October, at 12:29:
>dh-make should be deprecated :-)

I don't agree with that. dh-make is very useful in some cases. And I have
created a lot of own packages already, some of them without dh-make but I
know good sides of it.

Andriy.


-- 
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/20121012123020.gb...@rep.kiev.ua

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[John Paul Adrian Glaubitz]

On Fri, Oct 12, 2012 at 12:06:11PM +0200, Benjamin Drung wrote: 
> Thanks.
> 
> I have setup a poll for it:
> 
> https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/

I voted, thanks!

Cheers,

Adrian


signature.asc
Description: Digital signature

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Benjamin Drung]

Am Freitag, den 12.10.2012, 21:13 +0900 schrieb Hideki Yamane:
>   - bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed
> Development, as Ubuntu packaging guide says) way, but now it heavily 
> relies on Launchpad in my point of view.

How does bzr-builddeb depend on Launchpad? bzr is integrated into
Launchpad, but you can use bzr without Launchpad as every other DVCS.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Hideki Yamane]

Hi,

On Fri, 12 Oct 2012 12:06:11 +0200
Benjamin Drung  wrote:
> I have setup a poll for it:
> https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/

 Thanks! :)  voted.

 My opinion is as BTSed,
  - dh-make is still usable for 1st step. Maybe experienced/skilled developer
don't need it (but needed it at least for me ;)

  - bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed
Development, as Ubuntu packaging guide says) way, but now it heavily 
relies on Launchpad in my point of view. And, packaging-dev can specify
vendor-specific Recommends/Suggest in its rules, then use it for Ubuntu
is meaningful.

(Well, LP is quite nice and Debian should consider to introduce its good
 point (user friendly web interface, etc), but I don't want to depend on
 it, sorry).

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20121012211342.4c62fb639fdcf095a73d6...@debian.or.jp

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Adam D. Barratt]

On 12.10.2012 12:49, Christoph Anton Mitterer wrote:

On Fri, 2012-10-12 at 10:09 +0800, Paul Wise wrote:

> I further looked around:
> e.g. the Release file seems to only use MD5 not so good :(
Wrong, the Release file has had all 3 since sarge. woody had MD5 & 
SHA-1.


Then what's this:
ftp://ftp.de.debian.org/debian/dists/sid/Release


It's a file containing MD5, SHA1 and SHA256 sums, as has already been 
explained to you.


/===
| $ wget -q ftp://ftp.de.debian.org/debian/dists/sid/Release
|
| $ sha256sum Release
| ca8a6b8809246a885e74600d2a61a0b73ead28dd0f324a682d8d3d359d82aa35  
Release

|
| $ grep -v "^ " Release
| Origin: Debian
| Label: Debian
| Suite: unstable
| Codename: sid
| Date: Fri, 12 Oct 2012 08:17:30 UTC
| Valid-Until: Fri, 19 Oct 2012 08:17:30 UTC
| Architectures: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390 s390x sparc

| Components: main contrib non-free
| Description: Debian x.y Unstable - Not Released
| MD5Sum:
| SHA1:
| SHA256:
\===

I'm struggling to see what point you believe you're making here.

Regards,

Adam


--
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/c881b1115792d5f04cc31b53c1bef...@mail.adsl.funky-badger.org

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Fri, 2012-10-12 at 13:49 +0200, Christoph Anton Mitterer wrote:
> Then what's this:
> ftp://ftp.de.debian.org/debian/dists/sid/Release

Ah... my bad... the file is simply truncated at some point... but I
guess this most be a local error.



On Fri, 2012-10-12 at 08:26 +0100, Adam D. Barratt wrote:
> You didn't look very far / well.
> Please check more carefully before making such assertions.

Yep... sorry for making stupid noise... should have noticed it already,
when the file was only the first 30 lines or so (as it appears here).


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

On Fri, 2012-10-12 at 09:17 +0200, Bernhard R. Link wrote:
> There is a disadvantage of having longer hashsums, thus making it harder
> for people to compare. The only reason that for those md5 is optimal and
> not crc32 is that there is only one md5 and there is a nice always
> available tool to compute it, so people can compare it more easy.

Do you think it often happens that people compare this manually? I
doubt... even for MD5,... cause whenever it goes above a few files, it
gets a pain with MD5, too.

And the tools for the newer alogs (well at least SHA2) are also quite
widespread now.


> Everything doing something like that can also create those sha2 sums on
> their own and use them. Using the debsums system (which has no security
> part at all) will only weaken security.
Well one argument would be, that these hashes are already created and
"automatically" maintained...


> So I think what you say is an
> argument for keeping md5sum, so that noone think they can use that
> information for security.
Wheter that works?! ;-)


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Christoph Anton Mitterer]

Hi Paul.

On Fri, 2012-10-12 at 10:09 +0800, Paul Wise wrote:
> > I further looked around:
> > e.g. the Release file seems to only use MD5 not so good :(
> Wrong, the Release file has had all 3 since sarge. woody had MD5 & SHA-1.

Then what's this:
ftp://ftp.de.debian.org/debian/dists/sid/Release


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Simon McVittie]

On 12/10/12 12:10, David Kalnischkies wrote:
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.

It depends what you're using it for: security is not magic pixie dust. A
hashing algorithm that is faster and equally collision-resistant is
better for integrity-checking (faster and no less secure), but worse for
password hashing (an attacker can try potential passwords faster).

>> Anyway... I guess it was clear, that I rather meant secure APT... dsc
>> files, Release.gpg, etc. pp.
> 
> APT will usually negotiate the checksum to use based on what it supports
> and what is included in the Release file.

Another relevant hashing algorithm is the one that GnuPG (as used by the
ftpmasters) uses to generate the signature for InRelease and
Release.gpg. For wheezy-as-testing, InRelease appears to be signed with
(RSA +) SHA1, which is the GnuPG default. In principle the ftpmasters
could configure gpg to sign with SHA256 (or even SHA512) in future,
assuming stable's gnupg (and preferably also oldstable's gnupg) can
verify such signatures.

squeeze's gnupg does seem to support the SHA-2 set of hashes (SHA224 up
to SHA512).

> Oh, and there is "Description-md5". I can't imagine a scenario in which it
> would be useful to change the English description of a package for an attack

This doesn't seem to matter, even if the descriptions were
security-sensitive. The signed file (In)Release(.gpg) contains MD5,
SHA1, SHA256 hashes of both Packages and Translation-*, so you can be
sure that nobody has modified Packages or Translation-* since they left
dak; and anyone who could cause dak to incorporate maliciously-colliding
descriptions (a DD or DM with upload privileges) could do more damage by
uploading a malicious .deb instead.

S


-- 
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/50780315.3010...@debian.org

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[David Kalnischkies]

On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
 wrote:
> algo,... not to mention that newer algos like Keccack are quite fast.

I wonder if it is really a good idea to search for a security checksum
based on the metric that it can be quickly calculated … but off-topic.


>> To use your example of dpkg file checksums, their purpose has _nothing_
>> to do with security.
> Well their _intended_ purpose,.. that's right.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so) and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.

I think adding "better" checksums here would just encourage people to
think that they could be used in a security relevant way.

And carrying bigger/more checksums around just means that we waste
everyones diskspace to keep up the illusion of security for some people.


> Anyway... I guess it was clear, that I rather meant secure APT... dsc
> files, Release.gpg, etc. pp.

APT will usually negotiate the checksum to use based on what it supports
and what is included in the Release file.
Supported is currently in squeeze (in wheezy):
MD5, SHA1, SHA256(, SHA512)
Usually found in a Release file is currently:
MD5, SHA1, SHA256
so it will take SHA256 and be done with it. apt-ftparchive/wheezy will
generate SHA512 by default as well, I am not sure about dak or others,
but that isn't really a problem just yet.

This falls apart of course as soon as RSA (or whatever ftpmasters will use
in this dystopia) is broken, but I guess we have a problem then anyway.

So dropping MD5 and/or SHA1 would be okay I guess, note through that
apt-get --print-uris outputs md5sum by default as some scripts can't cope
with other checksums. See #576420 as an example why, so you would need
to find and fix these scripts first I guess (or just break them of course).


There is one exception: pdiffs work entirely with SHA1, were is some work
pending on the dak side, I guess while incorporating them into APT we could
work on that. In case of an emergency you could just disable that optional
feature of course (user as well as server side). And in the end of all days,
really interesting is only a pre-image attack, collision is kinda boring …


Oh, and there is "Description-md5". I can't imagine a scenario in which it
would be useful to change the English description of a package for an attack
(which you want to hide by displaying the translations of the not modified
 version), but feel free to be the first to launch a successful pre-image
attack on long descriptions (with the "side" problem of not changing size
and checksum of the [compressed] Packages file including the description).

Beside, for Debian this "attack" becomes easier now as the translation is
split out and the md5sum therefore pre-calculated, so you can write whatever
you want in the Translation-* files as a description without caring for
Description-md5 ("side" problem still applies though).


Best regards

David Kalnischkies


--
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/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=ohoe2gg_rybwnc...@mail.gmail.com

Poll (was: Popularity of bzr-builddeb and dh-make)

[Benjamin Drung]

Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise:
> On Fri, Oct 12, 2012 at 5:35 AM, Benjamin Drung wrote:
> 
> > A poll is a good idea. Can you recommend a site that allows setting up a
> > poll?
> 
> The Debian secretary was at one point going to setup devotee for this
> sort of thing, don't think that ever happened though.
> 
> If you want some FSAAS (free-software-as-a-service), search for doodle
> on this page:
> 
> https://wiki.debian.org/FreedomBox/LeavingTheCloud

Thanks.

I have setup a poll for it:

https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/

The poll will be closed in one week (if enough votes are collected).

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: (seemingly) declinging bug report numbers

[Riku Voipio]

On Thu, Oct 11, 2012 at 09:45:58PM +0200, Simon Josefsson wrote:
> Marco Nenciarini  writes:
> > I've seen recently several company I'm working with getting away from
> > Debian in favor of Ubuntu because they have a LTS version. However I
> > don't know if this is a general trend.
 
> I can confirm the trend for a couple of organisations.  The primary
> reason that I identified was the retirement of security support for
> Lenny and that Lenny packages are removed from many Debian mirrors which
> made it difficult to use Lenny machines.  IMHO, supporting an OS release
> for only 3 years is not long enough.

Well the challenge is that everyone has a opinion what Debian should do,
but few are ready to WORK to make it happen. Getting volunteers to be
interested in maintining 3 years old release is hard enough. If companies
and organisations are not prepared to assign people to work on debian LTS,
it is unlikely to happen.

While people want LTS, they still want latest version of various apps
they use (browser, new gcc and python for some inhouse development, etc),
as well as support for all the new hardware they buy. Solving these two
goals at the same time is tricky. We'd like to have the cake and eat it
too.

My gut feeling is that when people say "We want long term support for
old distro releases", they mean "We have had so many bad experiences of
things breaking when upgrading the whole distro, that we'd rather not 
upgrade if possible". 

Which means the root of the problem is regressions when upgrading.

Riku


-- 
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/20121012084730.ga28...@afflict.kos.to

Re: Popularity of bzr-builddeb and dh-make

[Jon Dowland]

On Fri, Oct 12, 2012 at 04:03:53PM +1100, Craig Small wrote:
> Steve with his years of packaging experience is not probably a good
> sample of one to base this upon. I'd be curious to see if newer
> packagers use it or not.

I don't bother with dh-make anymore. Like Steve the (mixed-case! Argh!) .ex
(.EX) files just get on my nerves. A dh7+ rules file I can type from memory
now and that just leaves the minor convenience of having the control file
stanzas written out.


-- 
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/20121012083903.GB24924@debian

Re: Popularity of bzr-builddeb and dh-make

[Игорь Пашев]

dh-make should be deprecated :-)


-- 
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/CALL-Q8yL-UtZ9rDMqkAQim9wZJRM8Bea1=tsyj6bub_t+pt...@mail.gmail.com

Re: Popularity of bzr-builddeb and dh-make

[Neil Williams]

On Fri, 12 Oct 2012 16:03:53 +1100
Craig Small  wrote:

> On Thu, Oct 11, 2012 at 02:38:46PM -0700, Steve Langasek wrote:
> > dh-make isn't so relevant now that debhelper 7 exists.  cp
> > /usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch
> > --create, manually create debian/control and debian/copyright, and that's
> > about it.  
> 
> Steve with his years of packaging experience is not probably a good
> sample of one to base this upon. I'd be curious to see if newer
> packagers use it or not.

People around me @ work who are/were unfamiliar with Debian packaging
find the .ex files particularly useful as worked examples - especially
for the maintainer scripts, init scripts and manpage starters.

dh-make as an executable may have had it's day but the worked example
files are valuable and will remain so as long as the examples continue
to keep up with Policy.

-- 


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



pgpS5w2wtFzAE.pgp
Description: PGP signature

Bug#690293: Policy 5.6.24: Checksums-{SHA1,SHA256} are required by the archive software

[Ansgar Burchardt]

Package: debian-policy
Severity: minor

Charles Plessy  writes:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
>
>   In the .dsc file, these fields should list all files that make up the source
>   package. In the .changes file, these fields should list all files being
>   uploaded. The list of files in these fields must match the list of files in 
> the
>   Files field.

The Checksums-{SHA1,SHA256} fields were optional when they were
documented in Policy[1], but by now dak requires Checksums-{SHA1,SHA256}
to be present and listing all files in both .dsc and .changes files.

  [1] 

I suggest replacing both 'should's with 'must' in the paragraph quoted
above.

Ansgar


-- 
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/87txu0uoxf.fsf...@deep-thought.43-1.org

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Adam D. Barratt]

On 12.10.2012 01:30, Christoph Anton Mitterer wrote:

I further looked around:
e.g. the Release file seems to only use MD5 not so good :(


You didn't look very far / well.

$ wget -O- -q http://ftp.debian.org/debian/dists/squeeze/Release | grep 
-v "^ "

Origin: Debian
Label: Debian
Suite: stable
Version: 6.0.6
Codename: squeeze
Date: Sat, 29 Sep 2012 11:31:27 UTC
Architectures: amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips 
mipsel powerpc s390 sparc

Components: main contrib non-free
Description: Debian 6.0.6 Released 29 September 2012
MD5Sum:
SHA1:
SHA256:

Please check more carefully before making such assertions.

Regards,

Adam


--
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/8de9b71d74d88d059285a00be8b52...@mail.adsl.funky-badger.org

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Bernhard R. Link]

* Christoph Anton Mitterer  [121011 19:39]:
> On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
> > What makes sense is to use a hash that has the properties that are
> > needed for a particular application.
> Well... I think that's only really required if performance is very
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.

There is a disadvantage of having longer hashsums, thus making it harder
for people to compare. The only reason that for those md5 is optimal and
not crc32 is that there is only one md5 and there is a nice always
available tool to compute it, so people can compare it more easy.

> > To use your example of dpkg file checksums, their purpose has _nothing_
> > to do with security.
> Well their _intended_ purpose,.. that's right.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so) and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.

Everything doing something like that can also create those sha2 sums on
their own and use them. Using the debsums system (which has no security
part at all) will only weaken security. So I think what you say is an
argument for keeping md5sum, so that noone think they can use that
information for security.

Bernhard R. Link


-- 
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/20121012071732.ga4...@client.brlink.eu