Re: Is a bug RC relevant if it has an influence on the health of a person

[Goswin von Brederlow]

Jakub Wilk  writes:

> * Goswin von Brederlow , 2010-09-11, 19:46:
>> Because you are a reportbug novice. Novices are not allowed to play
>> with severity of bugs. :)
>
> I consider this a horrible misfeature of reportbug. Yes, we need RC
> bugs from novices, too.
>
> -- 
> Jakub Wilk

I like the middle ground where you have to justify the severity. Makes
people think twice.

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/87aanjic0n@frosties.localdomain

Re: /usr/share/info/dir.gz if install-info is installed

[Bernhard R. Link]

* Sebastian Andrzej Siewior  [100914 13:45]:
> Sounds reasonable. However sometimes package maintainer argueue that the
> policy says "clean build environment" and having package X intalled is
> no longer clean (thus I have a problem and buildds do not).

A package more installed is not a unclean build environment, only a
non-minimal. Otherwise how do you explain that there is a Build-conflict
field?

Packages not building in a real environment is a serious problem for our
infrastructure. Having some extremely special build environment for your
software betrays one of the most important principles of free software:
Every user is a possible developer and should be enabled to hack on it.
The easy solution is to allow packages to be build in any clean
environment (i.e. a normal Debian system with no 3rd party stuff
installed and no absurd changes). Requiring users to use tools to create
an artifical work environment is bad enough and might be made only bad
and not totally unacceptable by easy to use tools (and while those are
good enough for a DD now I still think they are still inacceptable
complex for non-DDs). But real work usually needs some partial compile,
taking a look at the messages, doing changes, resuming compile, and so
on. Doing this effectively in a minimal environment will already be
beyond the capabilities of most DDs, not even to speak about regular
users.

I thus hope more buildds will install packages like install-info to make
sure we do not ship buggy packages (How about adding that to some fast
ones like i386 and amd64?).

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/20100915100635.ga21...@pcpool00.mathematik.uni-freiburg.de

Re: /usr/share/info/dir.gz if install-info is installed

[Ian Jackson]

Bernhard R. Link writes ("Re: /usr/share/info/dir.gz if install-info is 
installed"):
> Packages not building in a real environment is a serious problem for our
> infrastructure. Having some extremely special build environment for your
> software betrays one of the most important principles of free software:
> Every user is a possible developer and should be enabled to hack on it.

Yes.

> The easy solution is to allow packages to be build in any clean
> environment (i.e. a normal Debian system with no 3rd party stuff
> installed and no absurd changes).

I hope no-one will disagree with this.  However, a malfunctioning
build isn't always a release-critical bug.

Julien Cristau  wrote:
> I'd say they're serious bugs if packages in the archive suffer from
> the misbuild, and normal ones if not.

I agree.

Ian.


-- 
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/19600.42609.822955.491...@chiark.greenend.org.uk

Re: Bits from keyring-maint

[Thomas Hochstein]

Christian PERRIER schrieb:

>> I would like to know the process which lead to selecting these figures.
>
> Apparently, just like many other things in the project: the folks
> doing the work (and appointed for this by the project through the DPL)
> examine the situation, make plans and decisions and
> then announce them.

All well and good, but perhaps they care to share the reasoning
leading to that decision. ;)


-- 
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/ldd.1009151354.2...@thorondor.akallabeth.de

Re: /usr/share/info/dir.gz if install-info is installed

[Sebastian Andrzej Siewior]

* Peter Samuelson | 2010-09-14 16:19:54 [-0500]:

>
>[Sebastian Andrzej Siewior]
>> Sounds reasonable. However sometimes package maintainer argueue that the
>> policy says "clean build environment" and having package X intalled is
>> no longer clean (thus I have a problem and buildds do not).
>
>Where does the policy say that?
>I can't find anything that even implies it.

Okay, my fault. I learned that from [0] which is not the policy but
intepretation of it.

>Peter

[0] http://lists.debian.org/debian-devel/2008/12/msg00919.html

Sebastian


-- 
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/20100915121620.ga14...@chamillionaire.breakpoint.cc

Re: Bits from keyring-maint

[Marco d'Itri]

On Sep 15, Christian PERRIER  wrote:

> > I would like to know the process which lead to selecting these figures.
> Apparently, just like many other things in the project: the folks
> doing the work (and appointed for this by the project through the DPL)
> examine the situation, make plans and decisions and
> then announce them.
I suppose that this was not the result of cargo cult engineering, so if
these new recommended key values have been selected as the result of a
process I am curious to know the rationale which lead to the choice.
It really looks like a simple question to me.

I am just asking for a rationale. I would like to know if the new
recommended key values have been selected as the result of a process,
and what the rationale is, or if this is cargo cult engineering.

> I somehow understand you might be unhappy about this way to do
> things. Is this interpretation from my side?
Assumingly this is the result of an informed choice, then I have no
objections at all.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from keyring-maint

[Christoph Anton Mitterer]

On Wed, 2010-09-15 at 15:14 +0200, Marco d'Itri wrote:
> I suppose that this was not the result of cargo cult engineering, so if
> these new recommended key values have been selected as the result of a
> process I am curious to know the rationale which lead to the choice.
> It really looks like a simple question to me.

I guess the reason is probably quite easy, isn't it?

- 4096 bit is what can be created with gnupg, without any patching and
it is supported to be used by all major RFC 4880 implementations
(without any patching).

- The primary key should be only used for signing other keys anyways,
and dedicated signing subkeys to sign data. Therefore it's not a big
deal (performance-wise) if the primary is "very large".

- One can clearly expect that computation-power advances, and lower
keysizes won't be enough in the future (even 4096 at some point of
time).


As long as ECC is not available in OpenPGP (and well tested in GnuPG),
it also makes sense to me to suggest RSA instead of DSA1/2.
Attached is a mail from Werner at the metzdowd list, which nicely
explains why.



Cheers,
Chris.


Re: Debian encouraging use of 4096 bit RSA keys.mbox
Description: application/mbox


smime.p7s
Description: S/MIME cryptographic signature

Re: /usr/share/info/dir.gz if install-info is installed

[Ian Jackson]

Sebastian Andrzej Siewior writes ("Re: /usr/share/info/dir.gz if install-info 
is installed"):
> Sounds reasonable. However sometimes package maintainer argueue that the
> policy says "clean build environment" and having package X intalled is
> no longer clean (thus I have a problem and buildds do not).

It would be nice if there were a way for the maintainer of a package
like install-info, which could be expected to (and is now known to)
cause misbuilds, to declare this problem.

Eg:

  Package: install-info
  Build-Lossages: install-info

  Package: python2.3-minimal
  Build-Lossages: python-version-detect

The result would be dpkg-checkbuilddeps failing like this:

  dpkg-checkbuilddeps: Probable build lossages, not mentioned in 
Build-Lossages-Permit:
  dpkg-checkbuilddeps:  package install-info causing install-info lossage
  dpkg-checkbuilddeps:  package python2.3-minimal causing python-version-detect 
lossage

If you had a package which doesn't do python version autodetection (eg
doesn't byte-compile) and doesn't mind what you have installed you
could say:

  Source: python-frobnicator
  Build-Lossages-Permit: python-version-detect

Probnably, mentioning a package by name (not by virtual package) (and
if applicable by matching version number) in Build-Depends should
cause that package's Build-Lossages to be ignored.

At the moment, a binary package can be:

  * In build-essential: implicitly Depends for all builds

  * Not in build-essential: "don't care" for naive source packages
 (ie sources which don't mention this package particularly)

My proposal provides the additional:

  * Declares Build-Lossages: equivalent to a declared 
 Build-Conflicts for all naive sources.  Sources which can
 tolerate this package (or must depend on it) 

This would be most useful for compatibility versions.  The user who
installs a compatibility library or otherwise knows what they're doing
can specify --ignore-lossages or something.

Would maintainers actually be willing to add such a field to their
package ?  There is no point in this if maintainers (eg of
install-info) are normally going to say "sorry the bug is in all the
other 100 packages, not in my package".

Ian.


-- 
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/19600.52207.966968.858...@chiark.greenend.org.uk

Re: Bits from keyring-maint

[Perry E. Metzger]

On Tue, 14 Sep 2010 16:56:50 + "brian m. carlson"
 wrote:
> On Tue, Sep 14, 2010 at 09:59:16AM +0200, Marco d'Itri wrote:
> > On Sep 14, Gunnar Wolf  wrote:
> > 
> > > pushing Debian towards adopting stronger RSA keys - We have
> > > accepted some 2048R keys, but if you don't have a real reason
> > > to keep your key at that size (i.e. you very often build on
> > > underpowered machines where a 4096R key takes forever, or
> > > something like that), we really prefer to go with 4096R keys.
> > I would like to know the process which lead to selecting these
> > figures.
> 
> I suspect that those figures are because 2048 bits is the default
> size for RSA keys and 4096 bits is the largest size that GnuPG
> supports. Some specially patched versions of PGP can support keys
> of up to 16384 bits, but IIRC those are all v3 RSA keys, which
> aren't allowed anymore.
> 
> Personally, I can't see a reason that using an RSA 4096 bit key
> should be that painful even on very slow machines.  You're
> performing a *single RSA encrypt operation* per signature.

The selected key length seems unreasonably long to most people who
have been discussing this on the cryptography mailing list I run. In
fairness, some call it harmless, but no one has defended it as
appropriate.

I will remind everyone that RSA key lengths do not provide linear
increases in security -- a 2N length is not twice as hard to brute
force as an N length, but rather many orders of magnitude harder. A 2N
key is also much slower to use than a key of length N, and although
this might seem like a small cost, it is not completely ignorable. It
is also harder to generate twice as many random bits reliably, the
hash functions used to defend the signed material may no longer be
of appropriate strength, etc.

It is telling that the DNSSEC trust anchor only uses a 2048 bit key,
and is far better defended than the keys Debian is using and arguably
a far more valuable key to steal.

Generally speaking, selecting a key length requires a threat model.
One must ask how people are likely to attack the security system the
keys are defending. The keys are being stored on people's personal
computers or on media in their homes without armed guards, safes,
tamper-resistant signing hardware, etc. There are very large numbers
of these keys. The keys are being used to sign software that comes
from upstreams with a variety of security policies, many of which are
fairly poor. The weak point is thus clearly not the keys.

Given that factoring even a 1024 bit number is difficult (and a 1200
or so bit number is probably beyond the financial capabilities of any
organization I can name, including major governments) no one is going
to be attacking the system by factoring.

For a fraction of the cost of doing detailed engineering studies to
factor a 2048 bit key (not even the actual factoring) I can conduct
targeted hacking attacks, have someone spend a few months gaining the
confidence of an upstream project so they can insert a subtle bug into
their code, hire a small army of skilled burglars to break in to the
physical locations where keys are stored or even conduct a supply
chain attack or dozens of other things. 4096 goes far beyond 2048.

I'm reminded of a rumored conversation that happened after Biham
discovered attacks on the NSA's Skipjack algorithm that limited its
security to around 80 bits. It was very noticeable that the designers
of the algorithm had picked an 80 bit key length as well. Reportedly,
this was described by someone in the know as an example of proper
engineering rather than as a coincidence. The professionals don't
reinforce a cardboard bridge with steel trusses.

Rather than recommend an increase to a key size that many will find
inconvenient, I would suggest worrying more about the process that
assures that what is being signed is in fact safe, and that keys are
not being misused. Several attacks against Windows recently have
involved stolen keys (note, stolen, not cracked) and I doubt Debian's
average key is better defended. Attackers look for weak points in
systems -- defenders must do the same.

Perry
-- 
Perry E. Metzgerpe...@piermont.com


-- 
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/20100915103530.439a2...@jabberwock.cb.piermont.com

Re: /usr/share/info/dir.gz if install-info is installed

[Bernhard R. Link]

* Ian Jackson  [100915 15:54]:
> Sebastian Andrzej Siewior writes ("Re: /usr/share/info/dir.gz if install-info 
> is installed"):
> > Sounds reasonable. However sometimes package maintainer argueue that the
> > policy says "clean build environment" and having package X intalled is
> > no longer clean (thus I have a problem and buildds do not).
> 
> It would be nice if there were a way for the maintainer of a package
> like install-info, which could be expected to (and is now known to)
> cause misbuilds, to declare this problem.

As this is not really a new problem and easy to check for, I'm more
surprised that is not yet catched by lintian. Or is there no lintian
run for buildd (i.e. unsourcefull) uploads yet?

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/20100915150505.gb22...@pcpool00.mathematik.uni-freiburg.de

Re: Bits from keyring-maint

[Marco d'Itri]

On Sep 14, "brian m. carlson"  wrote:

> I suspect that those figures are because 2048 bits is the default size
> for RSA keys and 4096 bits is the largest size that GnuPG supports.
FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from keyring-maint

[Felipe Sateler]

On 14/09/10 01:18, Gunnar Wolf wrote:
> - Your new key should be signed by two or more other Debian Developers

The NM and DM processes require only one signature. Why is it harder to
replace a key than to become a DD?

-- 
Saludos,
Felipe Sateler



signature.asc
Description: OpenPGP digital signature

Re: /usr/share/info/dir.gz if install-info is installed

[Jakub Wilk]

* Bernhard R. Link , 2010-09-15, 17:05:
As this is not really a new problem and easy to check for, I'm more 
surprised that is not yet catched by lintian.


It is: package-contains-info-dir-file. And it's even on ftp-master's 
autoreject list.


--
Jakub Wilk


signature.asc
Description: Digital signature

Re: Bits from keyring-maint

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Marco d'Itri wrote:
> On Sep 15, Christian PERRIER  wrote:
> > > I would like to know the process which lead to selecting these figures.
> > Apparently, just like many other things in the project: the folks
> > doing the work (and appointed for this by the project through the DPL)
> > examine the situation, make plans and decisions and
> > then announce them.
> I suppose that this was not the result of cargo cult engineering, so if
> these new recommended key values have been selected as the result of a
> process I am curious to know the rationale which lead to the choice.
> It really looks like a simple question to me.
> 
> I am just asking for a rationale. I would like to know if the new
> recommended key values have been selected as the result of a process,
> and what the rationale is, or if this is cargo cult engineering.
> 
> > I somehow understand you might be unhappy about this way to do
> > things. Is this interpretation from my side?
> Assumingly this is the result of an informed choice, then I have no
> objections at all.

I notice Perry E. Metzger's reply already address most of what I will
write here, but I had already composed most of the reply before I got
his, and I wrote a bit more about some of the details than he did.

As Perry said, the responses on the crypto ML are favorable on the bias
towards RSA.  Reasons given were compatibility outside of the gnupg
world, and decription speed.  There was one about code maturity, but I
am not sure I understood it correctly.

As for the large keysize, it is seen as too large.  It was recommended
that Debian should try to do something that would help reduce the
overall threat to the Debian PKI instead of promoting very large key
sizes *in order to acommodate for very large key lifetimes*.

The recommendation for that one was: smartcards, use main key as a KSK
only, and don't let it leave the smartcard.  subkeys have several
advantages, they can be smaller than the main key, and they can be
replaced without web of trust issues (so you could replace them often,
and give them a validity of only 1-2 years).

One would use the smartcard only to generate new subkeys and UIDs, and
to sign other keys (otherwise, you'd need to re-sign already-signed UIDs
when the subkey is about to expire. I didn't check if gnupg lets you use
subkeys to sign UIDs on other keys).

Message encription and signature are done using the subkeys, only.
Subkeys are much easier to replace, can be smaller (i.e. faster to use)
than the main key, can be of a different type (e.g. El-Gammal) than the
main key, and replacing them won't interfere with the web of trust.

I just wondering where I am supposed to find a good smartcard that can
take 2048R (or larger) keys, works well with gnupg, and for how much :)

The usual question (what is the threat model for DD keys) was obviously
asked, and as usual the first threat that comes to mind is not key
cracking or colision attacks by a well-funded attacker.  It is not
technological advancement (for which the best defense is to be able to
upgrade keys often and making sure such key rollovers can be done
safely).  It is a compromised key, which is much cheaper and easier to
accomplish, and could be done by a lucky script kiddie.

IMHO there are NO reasons to believe we can take secure (which *are*
cubersome) key handling practices by every DD for granted, either.

BTW: Nobody was able to convice me that 4096R is a bad choice,
especially when coupled to 2048R subkeys.  Only that it is pointless to
use 4096R instead of 2048R for the overall Debian PKI security
standpoint.  But pointless does not mean harmful.

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


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

Re: Bits from keyring-maint

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Marco d'Itri wrote:
> On Sep 14, "brian m. carlson"  wrote:
> > I suspect that those figures are because 2048 bits is the default size
> > for RSA keys and 4096 bits is the largest size that GnuPG supports.
> FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.

Hmm, that IS interesting.  Do you have a link handy?

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


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

Re: Bits from keyring-maint

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Felipe Sateler wrote:
> On 14/09/10 01:18, Gunnar Wolf wrote:
> > - Your new key should be signed by two or more other Debian Developers
> 
> The NM and DM processes require only one signature. Why is it harder to
> replace a key than to become a DD?

Or rather, why the requirements for the first key any weaker than those
for DD key replacement?

Do we have a wiki page with all project crypto policies and expected
crypto material handling practices?  That could be a powerful tool to
increase awareness AND spot such inconsistencies...

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


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

Re: Bits from keyring-maint

[Perry E. Metzger]

On Wed, 15 Sep 2010 12:41:49 -0300 Henrique de Moraes Holschuh
 wrote:
> On Wed, 15 Sep 2010, Felipe Sateler wrote:
> > On 14/09/10 01:18, Gunnar Wolf wrote:
> > > - Your new key should be signed by two or more other Debian
> > > Developers
> > 
> > The NM and DM processes require only one signature. Why is it
> > harder to replace a key than to become a DD?
> 
> Or rather, why the requirements for the first key any weaker than
> those for DD key replacement?

Or rather, what is the specific threat that the policy is designed to
address? Does it succeed?

Perry
-- 
Perry E. Metzgerpe...@piermont.com


-- 
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/20100915115725.14455...@jabberwock.cb.piermont.com

Moving package with quilt to new upstream version

[Giuseppe Sacco]

Hi all, I have recently packaged hylafax 6.0.4-10 using quilt. Now I am
moving to a new upstream release 6.0.5 and I am trying to update my
package following
http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream
but I failed to it properly.

What I do:
1. untar new upstream release 6.0.5
2. remove its debian directory
3. untar hylafax_6.0.4-10.debian.tar.gz into new source root
4. change debian version in changelog via dch
5. execute "while quilt push; do quilt refresh; done"

here it fails with message "No patches in series" because it doesn't
look for debian/patches/series but only for patches/series.

If I change to the debian directory and then issue the same command, I
get all patches rejected because quilt is looking for files to patch in
debian directory instead of its parent.

So, how do you move your quilt patches to a new upstream release?

Thanks,
Giuseppe


-- 
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/1284566327.4749.174.ca...@scarafaggio

Re: Moving package with quilt to new upstream version

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Giuseppe Sacco wrote:
> here it fails with message "No patches in series" because it doesn't
> look for debian/patches/series but only for patches/series.

You have to set the QUILT_PATCHES environment variable or tell quilt where
to find the patches through its config file.

"man quilt" explains it all.

IMO, you should try to get yourself better acquinted with quilt before
using it, or you can end up with a mess.

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


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

Re: Moving package with quilt to new upstream version

[Jordan Metzmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/15/2010 11:58 AM, Giuseppe Sacco wrote:
> 
> here it fails with message "No patches in series" because it doesn't
> look for debian/patches/series but only for patches/series.
> 

See section 3.1 of the New Maintainers Guide.


Regards,

- -- 
Jordan Metzmeier

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

iQIcBAEBCAAGBQJMkPMyAAoJEKj/C3qNthmTCXYQAIN+0XKdlHe85rRxRyvBk+9u
F/wsU4QNaWBWgnubrKqcR5u0N//EdT5kV5fDVEpVZFULoyJKTYxG6Y5BI2iiXg5I
aRFyWaI+o5ruJc3qRGHl56C0P3wL91wLcWE5sillV5RarOkIhyJcuUpMSTLVCrKP
azvI2UciE27wY0YmQMn5jc4O98hRZvGkRIqcPYOHniv7owf7SyFKXqdQISoF0Uo9
JSQmVPbTcsbNJciIknuUkYZl13Rhc7wN3FkLuHsPMlmaxmi8hLqv2geB3z335ZKE
jJ1XjUMXJZk+QRYyY44lSTo2sw6ACYi2cqZ+xhxgYFXASv6IH1HRk+8J9n8aT2Hx
YWMc5yD5sXH4PJ/vvHfmU4bXhsNJHlQptv2Ud3k4+eyktW4k/9Oe5p5lPM7aDXCx
ukWh6X+zx+1au/gbVC3alQMgMYEKkTnPniCy2LXLr2Vcq2wvuuRoU9d92l5Pjz1w
i81tbix5eHNC6sC4sF9Pzse9iC1HtK5ge6+f1wlPYK60JbxL8jVlhK7ZJNtX7w+j
1z/ONdMPYrWinB0gTT5q3pVx6eVkNAzryX2Mrw6+AtvbaDtZNcwaE8t9Dy163//h
mE173L5x/ebMTb+2WZHHSvTrYrl1BTR8EDBAzYsje8etFPy5WTpwTFIrHVS1a6Z9
7HiKCj3n7DpRsBbvG+4P
=bIm2
-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/4c90f332.1030...@gmail.com

Re: Moving package with quilt to new upstream version

[Giuseppe Sacco]

Il giorno mer, 15/09/2010 alle 13.14 -0300, Henrique de Moraes Holschuh
ha scritto:
[...]
> "man quilt" explains it all.

thanks

> IMO, you should try to get yourself better acquinted with quilt before
> using it, or you can end up with a mess.

Right. That's why I am testing this process while upstream only produced
and rc version.

Thanks,
Giuseppe


-- 
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/1284568082.4749.190.ca...@scarafaggio

Re: Moving package with quilt to new upstream version

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Giuseppe Sacco wrote:
> > IMO, you should try to get yourself better acquinted with quilt before
> > using it, or you can end up with a mess.
> 
> Right. That's why I am testing this process while upstream only produced
> and rc version.

I've found that using dpkg-source format 3.0(quilt) inside a git tree
can be really annoying (do you commit the tree with patches applied or
unapplied? [unapplied works better for *my* workflow] either way, the
tree will be dirty for git at annoying times), BUT it helps a DAMN GREAT
DEAL to keep quilt in check, enough that I do it for every package I
take care of.

And "git clean -x -d -f ; git reset --hard" is a *MUCH* faster way to
clean up messes when a patch fails to apply and doesn't revert, than
anything I've ever used before.  It is also much faster than debclean.
Note: it will kill any non-git-commited changes.

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


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

Re: Bits from keyring-maint

[Michael Bienia]

On 2010-09-15 12:34:46 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 15 Sep 2010, Marco d'Itri wrote:
> > On Sep 14, "brian m. carlson"  wrote:
> > > I suspect that those figures are because 2048 bits is the default size
> > > for RSA keys and 4096 bits is the largest size that GnuPG supports.
> > FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.
> 
> Hmm, that IS interesting.  Do you have a link handy?

http://shop.kernelconcepts.de/product_info.php?products_id=42&language=en

You might also find this interesting:
http://www.privacyfoundation.de/crypto_stick/crypto_stick_english/

It's an OpenPGP v2 card with a USB smartcard reader in one enclosure.

Michael


-- 
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/20100915164131.ga11...@vorlon.ping.de

Re: Bits from keyring-maint

[Jonathan McDowell]

On Wed, Sep 15, 2010 at 03:14:48PM +0200, Marco d'Itri wrote:
> On Sep 15, Christian PERRIER  wrote:
> > > I would like to know the process which lead to selecting these
> > > figures.
> > Apparently, just like many other things in the project: the folks
> > doing the work (and appointed for this by the project through the
> > DPL) examine the situation, make plans and decisions and then
> > announce them.
> I suppose that this was not the result of cargo cult engineering, so
> if these new recommended key values have been selected as the result
> of a process I am curious to know the rationale which lead to the
> choice.  It really looks like a simple question to me.
> 
> I am just asking for a rationale. I would like to know if the new
> recommended key values have been selected as the result of a process,
> and what the rationale is, or if this is cargo cult engineering.

The key driver is moving away from SHA-1 based keys, but as part of the
same process we want to increase key length from 1024 bits. If you're
generating a new key and have no reason not to do so then we're
recommending 4096 bits (as the largest easily generated size with our
current tools). Yes, this is way beyond what anyone is going to be able
to attack, and there are many, many other easier attack vectors people
could use against Debian instead, but we do end up with keys hanging
around for a long time (10+ years in many cases) and we feel it makes
sense to rule out key strength as a problem given the increases in
processing power since we started out with 1024 bits.

We won't refuse 2048 bit keys; whether that be because you're using a
hardware OpenPGP smartcard, or have a slower machine and feel it makes a
big difference, or have just made an reasoned out decision that this is
sufficient.

J. (wearing a rather fetching keyring-maint hat)

-- 
Web [101 things you can't have too much of : 29 - T-shirts.]
site: http:// [  ]   Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24


signature.asc
Description: Digital signature

Re: Moving package with quilt to new upstream version

[Christoph Egger]

Giuseppe Sacco  writes:
> here it fails with message "No patches in series" because it doesn't
> look for debian/patches/series but only for patches/series.

export QUILT_PATCHES=debian/patches
-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


-- 
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/877hin53tu@chillida.ipv6.sieglitzhof.net

Re: Moving package with quilt to new upstream version

[Goswin von Brederlow]

Christoph Egger  writes:

> Giuseppe Sacco  writes:
>> here it fails with message "No patches in series" because it doesn't
>> look for debian/patches/series but only for patches/series.
>
> export QUILT_PATCHES=debian/patches

Actually not needed.

Just type "debuild" or "dpkg-buildpackage". It will apply the patches
the right way for you. Once it has done that once (even if it fails)
the .pc/ directory will contain the right path to the patches and series
file and subsequent quilt calls will work as expected.

If you want to do it by hand then

  QUILT_PATCHES=debian/patches quilt push

will do the same. You only need QUILT_PATCHES for the first quilt call.

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/87d3seg7lf@frosties.localdomain

Re: Moving package with quilt to new upstream version

[Henrique de Moraes Holschuh]

On Wed, 15 Sep 2010, Goswin von Brederlow wrote:
>   QUILT_PATCHES=debian/patches quilt push
> 
> will do the same. You only need QUILT_PATCHES for the first quilt call.

Is that so?  That would be good news, but it doesn't match my
experience...  although the last time I tried that was some months ago.
Is it new functionality in quilt, or something changed in the way dpkg
sets up .pc/ recently ?

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


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

Re: Moving package with quilt to new upstream version

[Bernd Zeimetz]

On 09/15/2010 06:33 PM, Henrique de Moraes Holschuh wrote:
> On Wed, 15 Sep 2010, Giuseppe Sacco wrote:
>>> IMO, you should try to get yourself better acquinted with quilt before
>>> using it, or you can end up with a mess.
>>
>> Right. That's why I am testing this process while upstream only produced
>> and rc version.
> 
> I've found that using dpkg-source format 3.0(quilt) inside a git tree
> can be really annoying (do you commit the tree with patches applied or
> unapplied? [unapplied works better for *my* workflow] either way, the
> tree will be dirty for git at annoying times), BUT it helps a DAMN GREAT
> DEAL to keep quilt in check, enough that I do it for every package I
> take care of.

Keep one branch with the patches applied and export them when you're ready to
build them - gbp-pq helps with that.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: 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/4c9128ad.1030...@bzed.de

Re: Bits from keyring-maint

[Tollef Fog Heen]

]] Henrique de Moraes Holschuh 

| I just wondering where I am supposed to find a good smartcard that can
| take 2048R (or larger) keys, works well with gnupg, and for how much :)

http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42
does 3072 bit keys and are quite reasonably priced.  AFAIK, the onboard
software isn't free, though.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends 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/87iq26sqzm@qurzaw.linpro.no

[RFC] Binary packages containing the source

[Hector Oron]

Dear developers,

ABSTRACT
  How to enable in some special cases a way to allow one source
package have multiple maintainers within Debian archive.

RATIONALE
  There are already a number of packages in the archive which ship
sources in a binary package, in some cases this is very useful, so
without having to duplicate the sources, there can be multiple
maintainers for one source without having to be forced to team up.
Ideally, a package should have a binary and a source part, but in some
cases it is very useful to provide this kind of packages, as it is the
case for GCC/EGLIBC/LINUX/BINUTILS (toolchain) packages, so ADA, JAVA,
D or cross compilers do not need to ship sources along the package.
So, basically what it is being done by some packages is to build
depend on those binaries shipping the source (*-source) to provide
tweaked or new binary packages with different configurations.

  Let's make an example, I would like to have a uClibc cross
toolchain, most sources are already in the archive and my changes
might be to intrusive to the packages itself, plus I need to talk to
different developers to coordinate the effort and rely on their
kindness to apply patches for something they might not feel like
maintaining. I might also want to generate packages for one
architecture which builds for any architecture and have different
source packages named uclibc-sh4, uclibc-avr32, uclibc-powerpcspe,
uclibc-armel,... Imagine if one needs to ship *same* source per each
one on those packages, this is bloating the Debian archive.

SOLUTION
  Approaches I could work on my own without bother anyone could be:
 a) build depend on *-source binary packages, which it is already a
practice and it does not need any infrastructure changes but there is
lack of standarization among those packages, some of them ship patches
aside with unpatched source, some others patched source, source might
be compressed and compression might change from time to time. IMO
should it should be fixed and standarized in Debian Policy and have
binary -source packages which contain .dsc, .diff.gz, etc. Comments?

  Other alternatives commented on IRC to be able to allow one source
for different maintainers:
  b) Have one *.orig.tar.gz and allow several *.diff.gz, which it is
probably a bad idea, as it requires infrastructure changes and diffs
need to be coordinated whenever a new *.orig.tar.gz appears.
  c) allow build depends on source packages, which it is probably a worst idea.
  d) team up or die.

  A list of packages that might be useful to provide in such way I can
think of right now are:
   linux-2.6, eglibc, binutils, gcc-X.Y, gdb, busybox, uclibc, newlib, ...

  Any comments on standarizing such behaviour in Debian Policy?

Best regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/aanlkti==�fe9axvpst_vr+s3ok=vrkhmccf+aka...@mail.gmail.com

Re: /usr/share/info/dir.gz if install-info is installed

[Sebastian Andrzej Siewior]

* Bernhard R. Link | 2010-09-15 17:05:05 [+0200]:

>Or is there no lintian
>run for buildd (i.e. unsourcefull) uploads yet?

[0] says

"Those automated rejects will only be done on sourceful uploads to
unstable and experimental."

So I would say no, there isn't.

[0] http://ftp-master.debian.org/#rejections

>   Bernhard R. Link

Sebastian


-- 
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/20100915210411.gb18...@chamillionaire.breakpoint.cc

Re: Bits from keyring-maint

[Manoj Srivastava]

On Wed, Sep 15 2010, Henrique de Moraes Holschuh wrote:

> As for the large keysize, it is seen as too large.  It was recommended
> that Debian should try to do something that would help reduce the
> overall threat to the Debian PKI instead of promoting very large key
> sizes *in order to acommodate for very large key lifetimes*.
>
> The recommendation for that one was: smartcards, use main key as a KSK
> only, and don't let it leave the smartcard.  subkeys have several
> advantages, they can be smaller than the main key, and they can be
> replaced without web of trust issues (so you could replace them often,
> and give them a validity of only 1-2 years).

I did not like that, since the card presumably travels with the
 person, and thus has the potential of getting lost. I prefer to
 generate my main key and than store it on read-only media, away from
 any network or computer. The subkeys are what live on the card.

> One would use the smartcard only to generate new subkeys and UIDs, and
> to sign other keys (otherwise, you'd need to re-sign already-signed UIDs
> when the subkey is about to expire. I didn't check if gnupg lets you use
> subkeys to sign UIDs on other keys).

I use my card for everyday uses, and to sign emails. Signing
 keys is more involved, though that has ony happened 15 times for me so
 far.

manoj
-- 
If you keep anything long enough, you can throw it away.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
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/87pqweiqe6@anzu.internal.golden-gryphon.com

WifiAccess.com is for Sale

[Toby Clements]

To whom it may concern:

We wanted to bring to your attention that WifiAccess.com is available for
sale.

Please contact me with any questions you have regarding this sale.


Best Regards,

Toby Clements
Partner
+1.615.944.3501

RickLatona.com | Latonas.com | DigiPawn.com | DigiLoan.com | ccTLDs.com


-- 
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/56094.116.50.236.226.1284588963.squir...@www.mynatmail.com

Re: Bits from keyring-maint

[Jonathan McDowell]

On Wed, Sep 15, 2010 at 11:57:25AM -0400, Perry E. Metzger wrote:
> On Wed, 15 Sep 2010 12:41:49 -0300 Henrique de Moraes Holschuh
>  wrote:
> > On Wed, 15 Sep 2010, Felipe Sateler wrote:
> > > On 14/09/10 01:18, Gunnar Wolf wrote:
> > > > - Your new key should be signed by two or more other Debian
> > > > Developers
> > > 
> > > The NM and DM processes require only one signature. Why is it
> > > harder to replace a key than to become a DD?
> > 
> > Or rather, why the requirements for the first key any weaker than
> > those for DD key replacement?
> 
> Or rather, what is the specific threat that the policy is designed to
> address? Does it succeed?

The question for a key for a new DM/DD is "Are we sure this person is
who we think it is?". For a replacement key for an existing key it's
"Are we sure this key belongs to the person we already know of as a
different key, and that they want the key replaced.". The first is
simpler than the second and doesn't risk locking a developer out from
access to the project.

Personally I'd like to require 2 signatures for new DM/DDs but I
understand that would raise the bar to project entry in an unhelpful
fashion.

J.

-- 
  Documentation - The worst part   |  .''`.  Debian GNU/Linux Developer
  of programming.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.


signature.asc
Description: Digital signature

Re: [RFC] Binary packages containing the source

[Jakub Wilk]

* Hector Oron , 2010-09-15, 21:26:

 c) allow build depends on source packages, which it is probably a worst idea.


On the contrary, I think that allowing source packages to be installable 
in the same way as binary packages is an excellent idea. Imagine you can 
do:


apt-get install src:linux-2.6

which will install Linux sources into a standard location, or upgrade it 
if it's already installed.


Incidentally, this will allow to trivially implement data packages[0]: 
a dummy binary package could depend on its own source package.


[0] http://wiki.debian.org/DataPackages

--
Jakub Wilk


signature.asc
Description: Digital signature

Fwd: Add this id

[Anbu Rasan]

Dear all Web masters

I have near *300good *quality in all theme sites with less obl Doing *
3way* linkexchange..


plz add this chat id: *...@yesyeeoh.com*

Re: Bits from keyring-maint

[Eric Dorland]

* Marco d'Itri (m...@linux.it) wrote:
> On Sep 14, "brian m. carlson"  wrote:
> 
> > I suspect that those figures are because 2048 bits is the default size
> > for RSA keys and 4096 bits is the largest size that GnuPG supports.
> FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.
> 

Many of them actually support the 4096 bit keys, it's bugs in gpg that
prevent them from being used:

http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025411.html

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature