Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Zenaan Harkness]

> Debian-Jr, Debian-Med, Debian-Edu, Debian-Np, Debian-Lex

Is there a single place where all official Custom Debian Distributions
(CDDs - even a reasonable TLA), aka internal projects, are listed?

> These Custom Distributions use the technique of metapackages and have
> common goals and try to develop common technologies.

Should have a [EMAIL PROTECTED] list then...

> It would be easy to mention these under one common term for an easy

yes, that would be good

> reference.  In Oslo was a decision to name it "Custom Debian Distribution"
> and if we try to speak with each other we have to agree about some
> terms.  This thread shows that there is not yet an agreement and this
> sucks because we have to explain over and over again what we are talking
> about.

Actually, it feels to me like we've come to a rough concensus on Custom
Debian Distribution. There is agreement a single term is a good thing,
perhaps with sub-definitions. No one (unless I missed it) has proposed a
better name that hasn't had problems pointed out. I think.

> For instance we have defined a term "Package Pools" and everybody now
> knows what we are talking about ...

Exactly.

It comes down to people using it. How would one go about creating a
common location for pointers to all of these CDDs?

Then, it's up to the projects to start using the term. A list would I
think be very good for making cdd discussions stand out at this point -
there seems to be enough traffic. But perhaps I'm wrong, I don't know.

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Thomas Viehmann <[EMAIL PROTECTED]> writes:
> 
> > Hi.
> > 
> > Goswin von Brederlow wrote:
> > > PS: I favour method C and would esspecially like some feedback on the
> > > technical aspect.  Can a "_deb_signature" file be savely added to the
> > > end of a deb without breaking existing tools (apt/dpkg/dinstall)?
> > 
> > I'd favor C, too. (And with be I'd prefer "cat *.changes" over "tar" if
> > it's gonna be B...)
> > 
> > However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
> > _deb_signature ; md5sum my.deb"  gives two different lines, I'd think
> > signing the individual members of the deb, not the deb in itself is
> > preferable (or sign a list of md5sum's or whatever). (Even if there is
> > some way to restore the old deb, I'd think something like the above
> > should be possible.)
> 
> I suggest making the signature a rfc822 formated file including some
> aditional information about the build environment:

Actually drop this in favour iof debsigs.

MfG
Goswin

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > What can we do with deb signatures?
> > 
> > For our current problem, the integrity of the debian archive being
> > questioned, the procedure would be easy and available to every user:
> > 
> > 1. get any clean Debian keyring (or just the key signing the keyring)
> > 2. verify the latest Debian keyring
> > 3. verify that each deb was signed by a DD and the signature fits
> 
> The canoical attack against signed debs in this situation is to find a
> signed deb on snapshot.debian.net that contains a known security hole.
> Now inject it into the compromised archive, with a changed filename, and
> edit the Packages file to have its md5sum. Now a user's checks will
> succeed -- the package is signed with a developer's key -- but they will
> install the old, insecure .deb. The only hint will be a warning from
> dpkg that it is downgrading the package, and a clever attacker might
> avoid even that.

How would you avoid it?

If a compromise is suspected the Packages file can be recreated from
the actual signed names and versions inside the deb. apt/dpkg can be
made to check this before unpacking a deb too.

> I would still like to be able to produce signed debs, it's another layer
> of security, but they are no panacea.

So far it looks like we just have to run debsigs on each way station
to get a continous trust chain that is currently interruped at master
when the changes files split out to the lists only.

MfG
Goswin

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 13:42, Niall Young wrote:
> On 2 Dec 2003, Zenaan Harkness wrote:
> 
> > - debconf package configurations (with "enterprise" defaults)
> 
> To me this is still the largest hurdle, having to work around packages
> that don't yet use debconf,

AIUI, policy will not change "should" to "must" until enough packages
already support debconf - otherwise you break too many packages with RC
bugs and testing goes dormant for centuries (well, too long anyway).

Solution: if it's important to you, get in and start finding packages
which could use debconf, and email the maintainers for discussion, and/
or supply patches if you have time and knowledge.

> install of every package in Debian, pre-seeding debconf, or even a
> separate Debian "registry" if debconf isn't meant to work like this, so
> you could replicate a system 100% accurately.  Even being able to apply
> a new debconf/registry profile and then asking all packages to
> reconfigure, that would be impressive.

There are many potentially nice features. It is happening and their is
interest - FAI, debix, debian-enterprise and other Custom Debian
Distributions (aka subprojects, metadistros and flavours) - basically
various groups would like such facilities, so it's a shared feature
wish.

> Then it's just a matter of customising anything not handled completely
> by debconf with, if you will, flavour-postinst etc. in a metapackage or
> udeb or flavour/class definition.  Flavours could consist only of Debian
> packages from the archive, plus this freely shared metapackage.  Perhaps
> this could even replace the task system eventually, including postinst

exactly - lost of cool stuff

> commands etc.  All of the value adding that flavours can provide will be
> in that last stage, modifying the default configuration, adding pretty
> interfaces or whatever..  Maybe the terms I've used are incorrect, I'm
> only vaguely familiar with metapackages/udeb etc. but you get the idea.
> Flavours simply become a wrapper or d-i hook performed after package
> installation, to utilise and remain 100% Debian.  Perhaps the flavour
> definition is hosted in the archive and policy compliant, perhaps not.

plenty of ideas, good stuff. Do you code and have time and have interest
to contribute?

> Building live CDs and non-interactive installs are relatively
> straightforward, but will remain a hack and a maintainer nightmare until
> the infrastructure enables and supports them imho.

Perhaps it really is getting to a good time to start a [EMAIL PROTECTED] list
(custom debian distributions) for all such topics ??

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Revival of the signed debs discussion

[John Goerzen]

On Tue, Dec 02, 2003 at 03:58:53AM +0100, Goswin von Brederlow wrote:
> John Goerzen <[EMAIL PROTECTED]> writes:
> 
> PS: Does debsigs just sign the control and data file or all files in
> the ar? What if we add some more files at some point (like a
> _buildinfo)?

It cats the control and data files together and signs the result.
Otherwise, an attacker could mix and match control and data files from
different .debs (as long as the files aren't modified) and still cause
havoc.

BTW, there is a design doc in /usr/share/doc/debsigs that describes some
of these things.

-- John

Re: apt-rpm article -- the features we don't have

[A.J. Rossini]

Maybe I'm missing something, but none of this sounds like
functionality that a bit of parsing  out to other programs can't
solve, given that I do it locally for the systems in my lab.

Joey Hess <[EMAIL PROTECTED]> writes:

> Interesting article on LWN: http://lwn.net/Articles/60650/ (subscription
> required) In summary, apparently apt-rpm users can now do some things
> with apt that we cannot.
>
> To install a package directly, with apt downloading any necessary
> dependencies:
>   apt-get install rpmver-2.0-13498cl.i386.rpm

couldn't this just refer to dpkg --install ?

> Similarly, to check the build depends of a source package file:
>   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm

similarly...?

> Next is a bit about local repositories that work w/o a Packages file.
> Instead of needing to keep the Packages file up-to-date, apt just scans
> the rpm files in the local repository directory. Of course this needs a
> file:// repository. Sounds just a smidgen easier than using
> mini-dinstall.

if there is a directory, a temporary run of dpkg-scanpackages plus...?


> There is something vague about improvements in the "upgrading
> algorythm" that may or may not apply to us.
>
> There is a bit about an apt shell which sounds mildly interesting.
>
> The rest of the new features seem more applicable to rpm than to deb.
>
> At least the first three things I've mentioned above would be nice
> features to have in debian. Not killer, but nice. Of course apt-rpm is a
> branch/fork from out apt, so I wonder how long it will be before we do..
>
> -- 
> see shy jo

-- 
[EMAIL PROTECTED]http://www.analytics.washington.edu/ 
Biomedical and Health Informatics   University of Washington
Biostatistics, SCHARP/HVTN  Fred Hutchinson Cancer Research Center
UW (Tu/Th/F): 206-616-7630 FAX=206-543-3461 | Voicemail is unreliable
FHCRC  (M/W): 206-667-7025 FAX=206-667-4812 | use Email

CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be
confidential and privileged. If you received this message in error,
please destroy it and notify the sender. Thank you.

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [031201 14:40]:
> > Instead of keeping extra files with the signature of the deb the
> > information could be stored inside the deb itself. Of cause the
> > signature can't be contained in the thing being signed. Instead the
> > signature would be added to the end or the ar archive and contain
> > signatures for all the files (uncompressed?) before it in the archive.
> > [...]
> 
> In principle I agree with your plan. Just a few suggestions what could
> (perhaps?) be also done:
> 
> I would like it even more if there would be something along each
> package that identifies what was done to the deb-file since creation
> (see it as a something like a "passport" or "signature file", where
> each entry adds new information to the file).
> 
> This would also have the advantage that a system administator could
> verify signatures without following who is accepted as a DD, and who
> is resigning - without a compromise of the debian server, verifying
> any deb with the archive key is enough. If there is however a
> suspecion of problems, he could always make stricter checks, without
> requiring more infos from the archive. (And of course, any
> administrator could also make checks stricter and demand a signature
> by a DD plus a signature by the archive script).

The Packages/Sources files with Release file already give that trust
chain. But given thats debsigs only adds 132 bytes to the deb having
signatures by the buildd, the uploader and dinstall looks feasable
space wise. You wouldn't gain any extra security from the dinstall
signature but it would mean one only has to check one method.

> More in detail this would mean that after building, the maintainer
> signs the md5sums, and a "build this package on ".
> 
> After accepted by the archive, the archive script adds a line with
> something like "accepted by katie on  because of good signature
> of  " to the top, and signs the whole thing.
> 
> This has one major drawback: Either the deb-file must be changed
> during acceptance to the archive, or the "passport" must reside in an
> extra file. (And there is of course a "mixed mode" possible: Extra
> file at the moment, and after sarge is released, the files move within
> the deb.)

The changes can be added as _foobar files to the deb savely just like
debsigs does.

> Technical details should IMHO be discussed later, but a sample
> passport could look like:
> 
> accepted by katie on Mon,  1 Dec 2003 20:34:58 + because of good 
> signature of DD, KeyID 0x01234567
> build by DD on Sun, 30 Nov 2003 14:34:33 +0100
> mgetty-voice_1.1.30-6_i386.deb
> 450b2b4ffa0be49b43f7358099117f7d control.tar.gz
> fb00a05d140ec3e830d6227f3fdd743d data.tar.gz

All debs would contain the same string "accepted by katie on * because
of good signature of DD, KeyID *". Thats a lot of bytes wasted.
The date is already stored in the ar archive so thats wasted too.

Each signing instance should have an unique key. They key ID then
identifies who signed it and the reason (being allways the same) could
be documented in some Readme.

I agree with you that every instance along the way to the archive
should sign the package:

1. maintainer
2. sponsor
3. buildd
4. buildd admin
5. dinstall

debsigs allows for 10 chars for the name of the signature.
8 chars would be key ID.
1-2 chars could be used to denote the reason of the signature:

DM - DD maintainer
NM - non DD maintainer
DN - non maintainer upload by a DD
NN - non maintainer non dd upload
SP - sponsor
BD - buildd
BA - buildd admin
DI - deinstall

Or just letters from A-H.

MfG
Goswin

Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Anthony Towns]

On Mon, Dec 01, 2003 at 06:48:20PM +0100, Andreas Tille wrote:
> For instance we have defined a term "Package Pools" and everybody now
> knows what we are talking about ...

Of course, not everyone used the term "Package pools" for the same thing
originally.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgpZVHcxAQbI1.pgp
Description: PGP signature

Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Philip Charles]

On Tue, 2 Dec 2003, Anthony Towns wrote:

> Since I evidently didn't, I'm going to spell things out in as much
> boring detail as I can. If I don't end up insulting your intelligence,
> my apologies. :)

You have clarified the situation nicely.

>
> So, using my definitions, the following conclusions are (IMO) true:
>
>   * all flavours are policy compliant
Basically sorting the stable archive and modifying the the current
installation scheme to suit.  Technically easy.  The task and exclude
lists in debian-cd and a few meta packages, or modify the override-*-extra
files.  Been there, done that.

>   * some derived distros might be policy compliant
The final test being that the installation is completely apt compatable
with a Debian mirror?

>   * you can't always create a flavour to do what you want
Yes

>   * you can always create a derived distro to do what you want
Yes

>   * improving our mechanisms for supporting "flavours" helps derived
> distros and their users
And makes Debian more diverse and so more universal.

>   * we can improve our support for "flavours" by co-opting many of the
> techniques pioneered by derived distros
People who produce derived distros tend to think "outside the square" and
so can add a new dimention to Debian.

>   * a derived distro can be an internal Debian project, but won't ever
> be /as/ internal as a flavour
But always remain on friendly terms with those working outside Debian.

>   * distributing customised Debian distros is not only the way of the
> future, it's the way of the present!
Sure is, and Debian is by far the best distro for this purpose.

Phil.

--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> On Mon, 2003-12-01 at 13:34, Goswin von Brederlow wrote:
> 
> > We have no continous trust chain going from the maintainer (also
> > meaning buildd + admin), ftp-master.d.o, mirrors to the user. A
> > compromised dinstall on master could replace binary uploads with
> > trojan versions without any user being able to detect it.
> > 
> A compromised dinstall on ftp-master could also replace the keyring
> package with a new one containing an extra key, used to sign the new
> package and any other package they felt like.

You don't check the signatur of a debian-keyring update against a
known good keyring? Maybe the debian-keyring package could add some
magic to its pre/postrm to check the new keyring on updates to do this
automatically.

> Assuming that level of compromise, there's no recent to suspect that
> they couldn't have free reign adding anything to the archive they
> wanted.  Signed .debs gain you nothing here.

You can detect such a compromised keyring easily if you realy care. So
for people who care the debian-keyring can't be compromised this
way. And then signed debs gain security (in the problem we face now
tih the archive).

> Anyway, I digress from this, I'm replying to point out that we have
> exactly the chain of trust you want:
> 
> 
> Download the source package components, verify their MD5 signatures
> against the Sources file, verify the MD5 signature of the Sources file
> against the Release file and verify that file's GPG signature.  This
> proves that the package has successfully passed through the ftp-master
> process and entered the archive.

This ensures no mirror-in-the-middle attack was performed as already
stated in the original mail.

> To verify this was uploaded by a Debian developer, go to
> http://lists.debian.org/debian-devel-changes/ and find the Accepted
> message, verify that message's GPG signature and verify the MD5
> signatures of the files in that against the real files (this contains
> uploaded .deb signatures too).

Thats possible as long as lists.debian.org is up and running. Also an
attacker to lists.debian.org could erase the archive or the archive
gets lost in a harddisk crash. What then? Rebuild every deb in stable,
testing and unstable?

The point of the excercise was that the changes files are not
available to the general public in a crisis situation like now and are
not easily available at normal times.

MfG
Goswin

Re: autoconf AC_SYS_LARGEFILE

[Brian May]

On Mon, Dec 01, 2003 at 06:46:11AM +0100, Bastian Blank wrote:
> On Mon, Dec 01, 2003 at 09:53:48AM +1100, Brian May wrote:
> > You can find copies of the source code at
> > http://www.microcomaustralia.com.au/debian/experimental>.
> 
> the sources are broken, run autoreconf -i -f and lart the author.

Yes, that seems to have fixed the problem, thanks.
-- 
Brian May <[EMAIL PROTECTED]>

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Goswin von Brederlow]

christophe barbe <[EMAIL PROTECTED]> writes:

> On Mon, Dec 01, 2003 at 09:11:52PM +0100, Andreas Barth wrote:
> > > Before mass bug-filling, it would be necessary to make it mandatory
> > > which unfortunately is not the case right now afaik. 
> > 
> > Severity: wishlist
> > Where is the problem?
> 
> Waste of time ?
> If it's not mandatory, a full coverage will never happen and without
> full coverage, most avantages of md5sum are lost.
> In my opinion it's not difficult to add it to packages without it.
> As soon as it's mandatory, NMU in delayed queue will be justified and I
> am sure it would not be long to get full coverage.
> Of course that post-sarge.
> 
> I don't see why adding a md5dsum_are_mandatory clause to the debian
> policy would be difficult (what would be a good reason to not add md5sum
> to a package?). 
> 
> Christophe

Because they waste space and give 0 security. See other mail.

MfG
Goswin

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Goswin von Brederlow]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> John Goerzen schrieb am Monday, den 01. December 2003:
> 
> > Debsigs generates its signature by effectively cating the control and
> > data components of the ar file together, running that through gpg, and
> > storing the resulting signature data in a new component of the ar file.
> > I did test this back in 2001 and the code caused no problem for dpkg
> > extraction.  In short, if a system does not use debsigs, the whole
> > signature is invisible to the system tools.
> 
> Kinda off-topic but nowhere in the discussion the question of checking
> already installed files was adressed and it should be asked:
> 
> are there any plans to store md5sums of the maintainer scripts along
> with the current one that are already created for the data.tar.gz
> contents? I imagine an attacker to place a time bomb into a prerm script
> of an installed package and wait for his next chance.
> 
> AFAICS the only way to verify the contents of maintainer scripts
> automaticaly is to have the binary package, verify its contents via
> .changes or Release/Packages path, extract it and compare the files. Too
> complicated.
> 
> I would like to see the following things happen:
> 
>  - current md5sums file in control.tar.gz should contain
>checksums of really all files
>  - a signature of the md5sums file should be stored either in
>control.tar.gz or in the ar file itself
>  - new dpkg version should pickup the signature files and store them
>either in /var/lib/dpkg/info or in some alternative directory
>  - modify debsums to check the signature as well as maintainer scripts'
>checksums
> 
> Any additions, comments, etc.?

If you think files of a deb are compromised on your system what makes
you thing the md5sum files are not? Storing the md5sum files on-site
will only help against accidental (or stupid) changes.

Also since the complete deb is just as save as the md5sumsfile
contained in the deb it is pointless to have such. People who realy
want to store the md5sums file should create it during install time
(let dpkg do that). The md5sums file still requires one to download
the complete deb from a trusted source to verify the installed
system. But then why not just do a 1:1 compare?

After all this ranting about how useless a md5sums file is here's an
idea:

1. No md5sums files are contained in the deb itself.

2. dpkg-genchanges unpacks the deb (control and data) and creates a
   sorted md5sums file (sorted by md5sum, by filename or whatever. But
   reproducible). A signature of the md5sums file (md5sum of it?) is
   then added to the change file.

   To save time dpkg-deb could build the md5sums file and
   dpkg-genchanges gets told where to find it. But dpkg-genchanges
   should be able to create it on its own too.

3. dinstall include the md5sums-file-signature in the Packages.gz
   file.


The md5sums file can be recreated at any time from the locally
installed package. Computing the signature of it and comparing it to
the Packages file entry is then easy. If the signature doesn't match
we know that at least one file of the package has been changed. In
that case the pristine package can be downloaded to investigate what
was changed.

MfG
Goswin

PS: Maybe when introducing that a change to SHA1 could be done too.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Niall Young]

On 2 Dec 2003, Zenaan Harkness wrote:

> - debconf package configurations (with "enterprise" defaults)

To me this is still the largest hurdle, having to work around packages
that don't yet use debconf, and not easily being able to take a debconf
snapshot and apply it to another host.  Being able to do a Noninteractive
install of every package in Debian, pre-seeding debconf, or even a
separate Debian "registry" if debconf isn't meant to work like this, so
you could replicate a system 100% accurately.  Even being able to apply
a new debconf/registry profile and then asking all packages to
reconfigure, that would be impressive.

Then it's just a matter of customising anything not handled completely
by debconf with, if you will, flavour-postinst etc. in a metapackage or
udeb or flavour/class definition.  Flavours could consist only of Debian
packages from the archive, plus this freely shared metapackage.  Perhaps
this could even replace the task system eventually, including postinst
commands etc.  All of the value adding that flavours can provide will be
in that last stage, modifying the default configuration, adding pretty
interfaces or whatever..  Maybe the terms I've used are incorrect, I'm
only vaguely familiar with metapackages/udeb etc. but you get the idea.
Flavours simply become a wrapper or d-i hook performed after package
installation, to utilise and remain 100% Debian.  Perhaps the flavour
definition is hosted in the archive and policy compliant, perhaps not.

Building live CDs and non-interactive installs are relatively
straightforward, but will remain a hack and a maintainer nightmare until
the infrastructure enables and supports them imho.

Niall YoungChime Communications Pty Ltd
[EMAIL PROTECTED]Level 6, 263 Adelaide Terrace
Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000

"Are you a parent who would like to involve your kids in an iiNsanity
event?"
-- Jodie Evans, Mar 2003

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Mon, Dec 01, 2003 at 03:30:58PM +0100, Thomas Viehmann wrote:
> > However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
> > _deb_signature ; md5sum my.deb"  gives two different lines, I'd think
> > signing the individual members of the deb, not the deb in itself is
> 
> Please check out the debsigs package.  I wrote it when I worked at
> Progeny back in 2001, and Branden Robinson maintains it these days.  It
> does exactly that.

I was looking for this but looked for the wrong name. Someone
mentioned it on irc but couldn't give details.

debsigs seems to create a 72 bytes signature + 60 byte overhead for the
ar header (132 byte total). With that little size increase I would
even suggest having 3 signatures: 1. buildd, 2. uploader, 3. dinstall.

Too bad that way we don't include some info about the build
environment. Maybe an _buildinfo file could be added to the ar for
that. But thats another discussion.

MfG
Goswin

PS: Does debsigs just sign the control and data file or all files in
the ar? What if we add some more files at some point (like a
_buildinfo)?

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Hi.
> 
> Goswin von Brederlow wrote:
> > PS: I favour method C and would esspecially like some feedback on the
> > technical aspect.  Can a "_deb_signature" file be savely added to the
> > end of a deb without breaking existing tools (apt/dpkg/dinstall)?
> 
> I'd favor C, too. (And with be I'd prefer "cat *.changes" over "tar" if
> it's gonna be B...)
> 
> However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
> _deb_signature ; md5sum my.deb"  gives two different lines, I'd think
> signing the individual members of the deb, not the deb in itself is
> preferable (or sign a list of md5sum's or whatever). (Even if there is
> some way to restore the old deb, I'd think something like the above
> should be possible.)

I suggest making the signature a rfc822 formated file including some
aditional information about the build environment:

==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Origin: Debian
Build-Environment: unstable (Thu, 19 Nov 2003 17:47:49 UTC)
Date: Thu, 20 Nov 2003 20:47:49 UTC
Build-Method: buildd
Signer: m68k wouter-mrvn buildd
Trust: automatic
SHA1:
 75be134193f3a940ee5d5af250679e047d9a7d634 debian-binary
 711959f47ea9a0c5e6edf59586b31f9041d2ee9a22683 control.tar.gz
 e43c8ff612f84a3075741d8bdaa55ce1e5577ea2  1354349 data.tar.gz

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

iD8DBQE/w2CxH8SBz+0NfPoRAmEPAJ93YiamjMGYwSRrgvNWZzm8wqjQzACeJcvc
f2q/MVNwPFxzu7GQCS0+KEE=
=ZjFs
-END PGP SIGNATURE-
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Signer: m68k wouter-mrvn admin
Trust: manual
SHA1:
 75be134193f3a940ee5d5af250679e047d9a7d634 debian-binary
 711959f47ea9a0c5e6edf59586b31f9041d2ee9a22683 control.tar.gz
 e43c8ff612f84a3075741d8bdaa55ce1e5577ea2  1354349 data.tar.gz
 713e5f4413a8a030e55d1a9b56a71c00edd77ea3  632 _deb_signature

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

iD8DBQE/w2CxH8SBz+0NfPoRAmEPAJ93YiamjMGYwSRrgvNWZzm8wqjQzACeJcvc
f2q/MVNwPFxzu7GQCS0+KEE=
=ZjFs
-END PGP SIGNATURE-
==

The entries in _deb_signature should be _all_ files in the ar archive
_before_ the signature. Maintainer uploads would have just the
maintainers signature, buildd uploads would have two signatures, one
automatic from the buildd and one manual from the admin. "Signer",
"Trust" and "SHA1" fields would be mandatory. "Origin",
"Build-Environment", "Date" and "Build-Method" optional.

"Origin" is who build the deb. Default should be the person building and
only official debian debs should have Origin: debian.

"Build-Environment" is the distribution installed to build this package.
Stable uploads would have "stable (3.0R2)" there, all others usually
unstable (date). This allows to track when and how a package was build.

"Date" is the date when the package was build.

"Build-Method" is the software used to build the package. Possible
values could be buildd, pbuilder, sbuild, umlbuild, debuild,
dpkg-buildpackage, dh_builddeb, dpkg-deb.

"Signer" is the role the signer plays. For buildds it would be the
systems name, other values could be maintainer, security team, buildd
admin. This would be purly informational. Just because I claim to sign
something as "security team" doens't mean I should be doing that.  On
the other hand all packages on security.debian.org could be required
to have a "Signer: security team" with a gpg signature of a member of
said team.

"Trust" gives information how save the private key is held. I can think
of automatic and manual as values. Automatic would be for any
signature done without an actual person sitting there signing and
manual for the rest.

> Lets have some experiments:
> For me (i386), slink "dpkg -i" breaks, potato "dpkg -i" (version 1.6.14)
> works with an appended _deb_signature.

That is good to know. Anyone using slink shouldn't upgrade to sarge in
one go, if such a person exists and wants to upgrade. A one step
slink-sarge update probably wouldn't work anyway.

> BTW: This is offtopic, but it seems that potato is neither in debian/
> nor in debian-archive/?

Potato was dropped pending the sarge release getting underway two/three
month ago iirc.

MfG
Goswin

Re: make-kpkg question

[Goswin von Brederlow]

Liberty Young <[EMAIL PROTECTED]> writes:

> On Sat, 2003-11-22 at 09:35, Manoj Srivastava wrote:
> > On Wed, 19 Nov 2003 10:46:52 -0700, Liberty Young <[EMAIL PROTECTED]> said: 
> > 
> > > I'm building kernels for an embedded x86 product, and I'm falling in
> > > love with make-kpkg. My only problem is that make-kpkg
> > > --added-modules pcmcia-cs kernel_image modules_image doesn't do a
> > > depmod on the pcmcia-cs modules against the built kernel. I assume
> > > others have not run into this problem as default debian startup
> > > scripts do a depmod on the system...however, in an embedded product,
> > > every second that can be spared is needed. My goal is to just have
> > > make-kpkg build up images that can be just installed on a separate
> > > file-system (Compact Flash in my case) without any other work..
> > 
> > Umm, it does try a depmod on install:
> > if ( -d "/lib/modules/$version" ) {
> >   my $ret = system("depmod -a -F $realimageloc/System.map-$version 
> > $version");
> >  ...
> > }
> > $realimageloc is generally /boot. 
> > 
> > If you are installing on a chroot, that should work fine, I
> >  would think.
> > 
> > > Am i just missing something here, or is this truley just a 'feature
> > > request' bug that should be submitted to the maintainers of
> > > make-kpkg?
> > 
> > If you provide some more details on how the kernel-imagfe-X.XX
> >  .deb is installed, we may be able to help.
> > 
> > manoj
> > -- 
> I'm installing by tarball.  Unfortunately, my embedded OS doesn't have
> apt or dpkg (yet). I was thinking that make-kpkg modules_image or
> kernel_image would include in the packaged .deb a modules.dep that would
> include an updated modules.dep. 
> I can see the logic in updating modules.dep during the install process,
> and not having a modules.dep that accounts for both in the resulting
> .deb from kernel/modules_image. Or is this a policy thing? 

The modules.deb could contain just the lines that need to be added to
modules.dep. But then the postinst script would have to add them and
the postrm script rmove them. You can't have to complete modules.dep
in the deb since that would break with two different modules.deb
packages installed.

> Since it is an embedded distro without dpkg, I HAVE to provide both
> tarballs as my main distribution method, along with .deb and .rpm via
> alien. 
>  
> fakeroot alien --to-tgz  kernel-image-X.XX.deb pcmcia-modules-X.xx.deb
> after unpacking both tarballs into a ./foo directory, here's what is
> "broken" :
> 
> $ cd lib/modules/2.4.22-2.3-ts/
> $ ls kernel/drivers/net/ppp_async.o
> kernel/drivers/net/ppp_async.o
> $ grep 'ppp_async' modules.dep 
> /lib/modules/2.4.22-2.3-ts/kernel/drivers/net/ppp_async.o: 
> /lib/modules/2.4.22-2.3-ts/kernel/drivers/net/ppp_generic.o
> $ ls pcmcia/orinoco.o
> pcmcia/orinoco.o
> $ grep 'orinoco' modules.dep
> $
> 
> 
> so, modules.dep has ppp_async, but not orinoco, which is from pcmcia-cs
> modules (orinoco.o isn't there until i unpack the pcmcia-modules
> tarball). 
> This means that unless my embedded system does a depmod on bootup, then
> things like 'modprobe orinoco' are going to fail. 

You have to run the postinst scripts  or work around that some other
way.

MFG
Goswin

Re: Source only uploads? -- Survey evaluation

[Goswin von Brederlow]

Roland Stigge <[EMAIL PROTECTED]> writes:

> Hi Steve,
> 
> >> Unfortunately, there wasn't much response to this. Maybe this is 
> >> related to the big Debian KO.
> 
> > Or maybe because making technical decisions by voting is silly.
> 
> At this stage, I personally decided that more official efforts wouldn't
> be appropriate just to reflect the community's opinion (at least better
> than the preceding discussion) considering that source only uploads were
> enabled and disabled in the past without further notice or discussion
> otherwise.
> 
> Of course, we can take this as a base of further actions.
> 
> Finally, the "decision" isn't just "technical".

Source only uploads were afaik disabled because the uploaded source
would just disapear and never enter the archive afaik. It was just
easier to block them than to fix the archive scripts I guess.

MfG
Goswin

apt-rpm article -- the features we don't have

[Joey Hess]

Interesting article on LWN: http://lwn.net/Articles/60650/ (subscription
required) In summary, apparently apt-rpm users can now do some things
with apt that we cannot.

To install a package directly, with apt downloading any necessary
dependencies:
  apt-get install rpmver-2.0-13498cl.i386.rpm

Similarly, to check the build depends of a source package file:
  apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm

Next is a bit about local repositories that work w/o a Packages file.
Instead of needing to keep the Packages file up-to-date, apt just scans
the rpm files in the local repository directory. Of course this needs a
file:// repository. Sounds just a smidgen easier than using
mini-dinstall.

There is something vague about improvements in the "upgrading
algorythm" that may or may not apply to us.

There is a bit about an apt shell which sounds mildly interesting.

The rest of the new features seem more applicable to rpm than to deb.

At least the first three things I've mentioned above would be nice
features to have in debian. Not killer, but nice. Of course apt-rpm is a
branch/fork from out apt, so I wonder how long it will be before we do..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Joey Hess]

John Goerzen wrote:
> Please check out the debsigs package.  I wrote it when I worked at
> Progeny back in 2001, and Branden Robinson maintains it these days.  It
> does exactly that.

Unfortunatly, the method debsigs uses to add the signature to the .deb
provuces a file that apt (including apt-ftparchive) does not consider to
be a debian package. This makes it kind of hard to upload the result to
the debian archive. :-(

I filed bugs about this a long time ago, it is apparently blocked
waiting on the mythical dpkg 2.0 which is supposed to have its own
external ar program that generates more valid debs. See the bugs of apt,
dpkg, and/or debsigs (I forget which, and am offline) for details.

I'm *sure* there is some way around it that does not involve waiting on
dpkg 2.0, of course, if someone has the energy to work on it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Joey Hess]

Goswin von Brederlow wrote:
> What can we do with deb signatures?
> 
> For our current problem, the integrity of the debian archive being
> questioned, the procedure would be easy and available to every user:
> 
> 1. get any clean Debian keyring (or just the key signing the keyring)
> 2. verify the latest Debian keyring
> 3. verify that each deb was signed by a DD and the signature fits

The canoical attack against signed debs in this situation is to find a
signed deb on snapshot.debian.net that contains a known security hole.
Now inject it into the compromised archive, with a changed filename, and
edit the Packages file to have its md5sum. Now a user's checks will
succeed -- the package is signed with a developer's key -- but they will
install the old, insecure .deb. The only hint will be a warning from
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.

I would still like to be able to produce signed debs, it's another layer
of security, but they are no panacea.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian Enterprise - a Custom Debian Distribution

[David B Harris]

On Mon, 01 Dec 2003 13:53:02 -0800
Bruce Perens <[EMAIL PROTECTED]> wrote:
> >Are you still on good terms with some people at HP?
> >
> Yes. Has anyone discussed this with Bdale?

He hasn't participated in the thread yet.

> >I wouldn't mind getting paid well for the work
> >I do, but that's a rarity. (Why does money always need to get involved?)
> >  

> I admire those who don't have to consider money while fulfilling all 
> three of the above goals.

I meant more specifically, when corporate involvement is discussed :)
There's lots of other things companies can do without writing cheques.

> >What I'd really like to see is a company providing input, serving as a
> >central point for customer contact, and above all, actually
> >*supporting* the use of the end-product. ie: not being hostile to users
> >who run it, as is so often the case these days.
> >
> Yes, but let me add something. I think we will have failed if there is 
> only one company doing this. No lock-ins, no lack of choices, please. 
> That's one of the things wrong with RH/Fedora.
> 
> And I think I have the structure to make this work. I'm writing now, 
> should have something for you later today.

Sorry, yeah. I should instead have said "*their* company", not any one
company. The company they buy their hardware and support from. In my
mind, HP and IBM are paramount, since they also happen to be the only
two major suppliers for the shop I work in :)

Re: Some observations regardig the progress towards Debian 3.1

[Mike Fedyk]

On Sat, Nov 22, 2003 at 02:20:20AM +0100, Adrian Bunk wrote:
> libfoo version 2-1 isn't allowed to enter testing since this would make 
> myprog uninstallable in testing
> 
> myprog 5-2 isn't allowed to enter testing since this would make myprog
> uninstallable in testing.
> 
> These two packages need to go into testing at the same time, and the way 
> the testing scripts currently work this means they need manual hinting.
> 

It looks like the logic is correct for the testing scripts, but it gets so
much more complicated when there are 30+ packages interacting with each
other. 

> * it isn't consistent in all respects; e.g. although the package 
>   dependencies might have been fulfilled, it contained for some time a 
>   strange mixture of GNOME 1 and GNOME 2

I'm pretty sure that was because of hinting.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Enrico Zini]

On Mon, Dec 01, 2003 at 02:33:57PM -0600, Chad Walstrom wrote:

> >  - GNU ERP software project ?name?
> GNU Enterprise (gnue)  http://www.gnue.org/

I've just learnt of Cubit from South Africa: http://www.cubit.co.za/

Ciao,

Enrico

Re: Revival of the signed debs discussion

[Martin Michlmayr]

* Thomas Viehmann <[EMAIL PROTECTED]> [2003-12-01 15:30]:
> BTW: This is offtopic, but it seems that potato is neither in debian/
> nor in debian-archive/?

Potato is on archive.debian.org (in /debian-archive/dists).

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Backport of the integer overflow in the brk system call

[Frederik Dannemare]

Frederik Dannemare wrote:
Hi everybody,
just curious: any particular reason why we didn't see a backport any 
sooner of the integer overflow in the brk system call (see recent 
announcement by Wichert Akkerman: 
http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) 
like we did with the ptrace issue some time back?

Wasn't it (the brk vuln) considered to be threatening enough to justify 
a quick fix, or was it because the fix by Andrew Morton didn't say 
(kerne changelog) enough about the potential seriousness of the vuln, or?
forgot to say: hat's off to the forensics guys. great work! I really 
appreciate that we now know what helped the attacker gain root.

--
B/R,
Frederik Dannemare

Backport of the integer overflow in the brk system call

[Frederik Dannemare]

Hi everybody,
just curious: any particular reason why we didn't see a backport any sooner of 
the integer overflow in the brk system call (see recent announcement by 
Wichert Akkerman: 
http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) 
like we did with the ptrace issue some time back?

Wasn't it (the brk vuln) considered to be threatening enough to justify a 
quick fix, or was it because the fix by Andrew Morton didn't say (kerne 
changelog) enough about the potential seriousness of the vuln, or?

--
B/R,
Frederik Dannemare

Re: Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 06:45, Bruce Perens wrote:
> Thanks. I can't get to your site at the moment.

My ISP has been intermittent over the last week - obviously having
server troubles. Usually fine though.

Also if you were trying my personal domain: http://soulsound.net/, that
might still be propagating through the DNS servers.

http://debian-enterprise.org/ should work though. Hopefully the ISPs
servers are up again soon.

> I have just closed out some customer work that has been taking up 100%
> of my time, and am today writing a manifesto that I will post at
> userlinux.com .

Please CC us - [EMAIL PROTECTED]

> I am still negotiating with the large industry group that approached
> me about this project. When the price tag is north of $1M, it takes
> time. If that works out, they would fund 3-5 engineers full-time, plus
> myself and an admin to work on the aspects of this project that are
> important to their industry group. And only their industry group.

Good luck. Sounds like your usually inspiring win-wins.

>  Thus, there is room for participation of a number of vendors and/or
> industry groups, as well as direct participation by all of the various
> entities that would participate in Debian.

Of course. Good point to clarify too.

Regards
Zenaan
  
-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Assurance measures: ACM

[(mag)]

Hi!

Sorry for starting with the more boring part. Here is a short overview
of the assurance requirements of Common Criteria, and how they
are covered by Debian (in parenthesis).

This overview is made for the Adamantix developers, but might be
interesting for debian developers also.

This part covers ACM (configuration management). Debian is
really outstanding in this area. Watch out for further issues:)

ACM_AUT.2 Complete CM automation (appears at EAL6, which is a very high
assurance level. Haven't heard about a product above EAL4)
ACM_AUT.2.1D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_AUT.2.2D The developer shall provide a CM plan.
(This is in the policy manual. Nicely fine grained.)
ACM_AUT.2.1C  The CM system shall provide an automated means by which
only authorised changes are made to the TOE implementation
representation, and to all other configuration items.
(This is made by signing the changes file, and by the
ftpadmin approval).
ACM_AUT.2.2C  The CM system shall provide an automated means to support
the generation of the TOE.
(Build daemons)
ACM_AUT.2.3C  The CM plan shall describe the automated tools used in the
CM system.
(Developers reference)
ACM_AUT.2.4C  The CM plan shall describe how the automated tools are
used in the CM system.
(Developers reference)
ACM_AUT.2.5C  The CM system shall provide an automated means to
ascertain the changes between the TOE and its preceding version.
('tla what-changed' or 'cvs diff')
ACM_AUT.2.6C  The CM system shall provide an automated means to identify
all other configuration items that are affected by the
modification of a given configuration item.
(looking up reverse dependencies)

ACM_CAP.5 Advanced support (appears at EAL6)
(If ACM_CAP.5 seems to be too strong, ACM_CAP.4 is the same but without
13C-21C, and appears at EAL4)
ACM_CAP.5.1D The developer shall provide a reference for the TOE.
(version numbers of packages)
ACM_CAP.5.2D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_CAP.5.3D The developer shall provide CM documentation.
(policy manual, developers reference)
ACM_CAP.5.1C The reference for the TOE shall be unique to each version
of the TOE.
(Yes, each version have a different version number:)
ACM_CAP.5.2C The TOE shall be labelled with its reference.
(each package have its version number both in the file name
and in the control file)
ACM_CAP.5.3C  The CM documentation shall include a configuration list, a
CM plan, an acceptance plan, and integration procedures.
The configuration list shall uniquely identify all
configuration items that comprise the TOE.
(The CM plan, acceptance plan and integration procedures
are described in the policy manual and the developers
reference. The configuration list (dpkg -l) indeed lists
all configuration items (packages) with version number.)
ACM_CAP.5.4C  The configuration list shall describe the configuration
items that comprise the TOE.
(apt-cache show does just that)
ACM_CAP.5.5C  The CM documentation shall describe the method used to
uniquely identify the configuration items.
(Maybe the apt and/or dpkg man page is also part of the CM
documentation)
ACM_CAP.5.6C  The CM system shall uniquely identify all configuration
items.
(name, version)
ACM_CAP.5.7C  The CM plan shall describe how the CM system is used.
(the docs are good)
ACM_CAP.5.8C  The evidence shall demonstrate that the CM system is
operating in accordance with the CM plan.
(debian/changelog, build daemon logs, etc. There might be minor
issues with it, but not much.)
ACM_CAP.5.9C  The CM documentation shall provide evidence that all
configuration items have been and are being effectively
maintained under the CM system.
(see above)
ACM_CAP.5.10C The CM system shall provide measures such that only
authorised changes are made to the configuration items.
(The debian keyring and the ftpmaster)
ACM_CAP.5.11C The CM system shall support the generation of the TOE.
(Build daemons)
ACM_CAP.5.12C The acceptance plan shall describe the procedures used to
accept modified or newly created configuration items as part of
the TOE.
(policy manual)
ACM_CAP.5.13C The integration procedures shall describe how the CM
system is applied in the TOE manufacturing process.
(policy manual. unstable, testing, stable, proposed-updates,
etc)

ACM

Re: Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 07:31, David B Harris wrote:
> On Mon, 01 Dec 2003 11:45:35 -0800
> Bruce Perens <[EMAIL PROTECTED]> wrote:
> > I am still negotiating with the large industry group that approached me 
> > about this project. When the price tag is north of $1M, it takes time. 
> > If that works out, they would fund 3-5 engineers full-time, plus myself 
> > and an admin to work on the aspects of this project that are important 
> > to their industry group. And only their industry group. Thus, there is 
> > room for participation of a number of vendors and/or industry groups, as 
> > well as direct participation by all of the various entities that would 
> > participate in Debian.
> 
> Are you still on good terms with some people at HP? I don't even think
> we need funding, per se. I wouldn't mind getting paid well for the work
> I do, but that's a rarity. (Why does money always need to get involved?)

To the level you are prepared to contribute, with or without funding, a
big thanks! And a double thanks when you do so without funding.

That said, if _any_ of us can get funding for what we do, we absolutely,
unequivocally should, in my opinion. I see no reason for money not to
enter discussions, if it is along the lines of "here's a possibility one
or more of us can get paid for at least some of the work we do".

I see such conversations as particularly valuable (multiple meanings).

> What I'd really like to see is a company providing input, serving as a
> central point for customer contact, and above all, actually
> *supporting* the use of the end-product. ie: not being hostile to users

Service companies are the foundation of a truly *free* free market
economy. Much closer to true competition and therefore optimal [resource
use|price to consumers|efficiency of production].

Either go start such a beast, or support those that already provide such
service, if you are so inclined to either.

> who run it, as is so often the case these days. I can't count the number
> of times I've heard horror stories from HP customers (and other vendors
> as well) about people being unable to RMA hardware because they're using

BTW, what's RMA stand for?

> a decent software bundle that they're familiar with and can maintain, as
> opposed to whatever outdated and bastardised crap was included with the
> hardware.

Hopefully things will improve. And the more money we can get as
developers within the community, the better.

> Okay, that sort of turned into a rant :) I do apologise, but I'd
> desperately like to help dispell the stigma that's associated with
> anything non-Red Hat.

I haven't personally come across such stigma at all. In fact my
experience is that Debian is somewhat esteemed, *technically*.

I think it has been perceived, though, that to be "pure and free", one
must not be "tainted" by consideration of money.

But that's complete bunk.

That's some poor-me's communistic dream. Take away motivation from
people and you end up with not only an expectation that all should be
provided for without lifting a finger, but poverty-conscious sorry
states of living that are a complete crock.

Now _I'm_ really ranting (and seriously, nothing personal in the
slightest).

Self-responsibility; intelligence; ability. If you've got it, make good
use of it, and Do Good Things (TM).

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)

[Andreas Barth]

* Gergely Nagy ([EMAIL PROTECTED]) [031201 23:10]:
> > * Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]:
> > > I think, at least Packages like "dpkg" or "gnupg" should call
> > > "dh_md5sums". I was wondering, if it would be usefull to make
> > > a mass bug-filling against these Packages. Before, it would be
> > > nice to have a List of Packages (maybe sorted by Maintainer)
> > > which do not call "dh_md5sums".
> > > 
> > > IMHO Lintian should also check if "dh_md5sums" is called and
> > > print at least a warning if this is not the case.

> > I agree with you, and I would support mass-filling, if first such a
> > list has been published here on d-d, together with the warning of
> > mass-filling.
 
> I disagree. Filing bugs on packages not having md5sums _might_ be ok,
> altough last time I checked, md5sums were only sugested, nowhere near
> a must in policy. Filing bugs based on missing calls to dh_md5sums is
> simply stupid. You don't need to build-depend on debhelper to have
> md5sums.

It was understood (at least from my side) that the checks should
actually be performed on the debs, and just for the existence of
md5sums, and of course not on the way of creating them. Everyone is
free to use the build tool he himself likes most. Sorry if I was
unclear about that.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Debian Enterprise - a Custom Debian Distribution

[Bruce Perens]

David B Harris wrote:
(I don't know if you're subscribed to debian-devel@lists.debian.org, so
I am resending this mail here.
It's best to copy me on things you want me to read. Also note that mail 
that doesn't have my address in the To: or Cc: field won't go to my main 
inbox and is usually discarded unread.

Are you still on good terms with some people at HP?
Yes. Has anyone discussed this with Bdale?
I wouldn't mind getting paid well for the work
I do, but that's a rarity. (Why does money always need to get involved?)
 

I've been successful at
   1. feeding my family
   2. keeping my ethics
   3. working full-time on Free Software and its issues
I wish everyone could be. It's not easy, and the means I have arrived at 
wouldn't work for very many people.

I admire those who don't have to consider money while fulfilling all 
three of the above goals.

What I'd really like to see is a company providing input, serving as a
central point for customer contact, and above all, actually
*supporting* the use of the end-product. ie: not being hostile to users
who run it, as is so often the case these days.
Yes, but let me add something. I think we will have failed if there is 
only one company doing this. No lock-ins, no lack of choices, please. 
That's one of the things wrong with RH/Fedora.

And I think I have the structure to make this work. I'm writing now, 
should have something for you later today.

   Thanks
   Bruce

Re: debian binary package

[Artur R. Czechowski]

Hello Frantisek,

On Sat, Nov 29, 2003 at 03:55:20PM +0100, frantisek hrbata wrote:
> /usr/local/lib/foo/ and manual pages in /usr/local/man/. when i invoke
> dpkg -r or -P, dpkg wants to delete directories like /usr/local,
> /usr/local/man and others. when a put files in right directories(binary
> files in /usr/local/bin and so on) everything is ok.

> i no, that this is against debian policy, but is there any way how to
> achieve this(to have files in non-standard directories and dpkg work
> correctly)
Well... Better try to modify your package to be conform with FHS.
Does your softwaer use autotools in build proces? Have you run ./configure
before make?

Cheers
Artur

PS. Please wrap lines at 72nd character.
-- 
Artur R. Czechowski <[EMAIL PROTECTED]>
JID:[EMAIL PROTECTED]  http://hell.pl/arturcz

Re: debsums for maintainer scripts

[christophe barbe]

On Mon, Dec 01, 2003 at 08:24:09PM +0100, Thomas Viehmann wrote:
> Michael Ablassmeier wrote:
> > IMHO Lintian should also check if "dh_md5sums" is called and
> > print at least a warning if this is not the case.
> In principle, I argree, but maybe it's better to check for the presence
> of an md5sums file than to "force" (haha) people who don't like it to do
> this.
> Attached is a linda patch that does that. Maybe I'll post a link the
> result of the run on my mirror later.

What about checking the content of the md5sum file? 

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

L'experience, c'est une connerie par jour mais jamais la même.

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[christophe barbe]

On Mon, Dec 01, 2003 at 09:11:52PM +0100, Andreas Barth wrote:
> > Before mass bug-filling, it would be necessary to make it mandatory
> > which unfortunately is not the case right now afaik. 
> 
> Severity: wishlist
> Where is the problem?

Waste of time ?
If it's not mandatory, a full coverage will never happen and without
full coverage, most avantages of md5sum are lost.
In my opinion it's not difficult to add it to packages without it.
As soon as it's mandatory, NMU in delayed queue will be justified and I
am sure it would not be long to get full coverage.
Of course that post-sarge.

I don't see why adding a md5dsum_are_mandatory clause to the debian
policy would be difficult (what would be a good reason to not add md5sum
to a package?). 

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

L'experience, c'est une connerie par jour mais jamais la même.

Re: Revival of the signed debs discussion

[Zenaan Harkness]

On Tue, 2003-12-02 at 07:00, Andreas Barth wrote:
> * John Goerzen ([EMAIL PROTECTED]) [031201 17:40]:
> > Even if the attacker could place a new keyring file in the archive,
> > people verifying signatures on signed .debs would not install it, since
> > it would not have the signature of a developer.
> 
> And to be honest: If all debs are signed, and it is easy possible, I
> would restrict accepted signatures at my private machine for the
> keyring package to James - and let me send a mail if there is a
> keyring package signed by any other DD. So, the real danger would be
> if James key is stolen.

Would it be possible && increase security for debian-keyring maintainer
to have a separate, non-network-connected box which which to sign any
new keyring packages (and transfers of the package, for signing,
happening by floppy/ cd/ etc)?

Would that give us long-term certainty that some unknown/ yet to be
discovered root-exploit has compromised our community without us
knowing?

ta
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: XML files referencing DTDs via HTTP

[Tom]

On Tue, Dec 02, 2003 at 07:48:04AM +1100, Brian May wrote:
> On Mon, Dec 01, 2003 at 01:51:31AM -0800, Tom wrote:
> > That's true.  It can be any string.  The fact that it just happens to 
> > look like an HTTP url and DTD is actually at that URL is not part of the 
> > standard, AFAIK.
> 
> Errr, we are not getting confused??
> 
>  "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; [

> Perhaps you were thinking of the PubidLiteral?

You're right.  I was thinking of the URLs used in XML namespaces.

On an orthogonal note, while DocBook is a good schema, the other more 
business-oriented schemas EBXML, Rosetta, HRXML, the Business reporting 
schemas, and all that stuff, are lousy.  "Here, kid, here's 50,000 
entities.  Have fun."

Re: Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 06:45, Bruce Perens wrote:
> Note there is also a gnUserlinux.org, but RMS objects to that name -
> he feels that people will percieve it as an official FSF project if
> the GNU comes first. This came as something of a surprise.

:)

I'd be betting you're not the only one.

However, knowing he very clearly defines what is and what is not part
of/ aligned with his philosophy on Free Software, I'd be pretty sure
there must be something about the gnUserLinux.org site that falls
outside what he can endorse.

That or he doesn't want the FSF to (or the FSF simply can't, perhaps
according to its charter) officially endorse anything that it does not
have an official agreement with.

Apologies to whomever I might be simply restating the obvious.

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Debian Enterprise - a Custom Debian Distribution

[Tom]

On Mon, Dec 01, 2003 at 03:31:29PM -0500, David B Harris wrote:

   > (Why does money always need to get involved?)

I think people start burnin' cars and shit if they don't have something 
to do all day.

> Okay, that sort of turned into a rant :) I do apologise, but I'd
> desperately like to help dispell the stigma that's associated with
> anything non-Red Hat.

I'm actually surprised more companies aren't trying to leverage the 
power of 1000 self-organized free developers.  I wonder if there would 
be a backlash if a Lindows did $1 billion revenue...

Re: Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)

[Gergely Nagy]

> * Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]:
> > I think, at least Packages like "dpkg" or "gnupg" should call
> > "dh_md5sums". I was wondering, if it would be usefull to make
> > a mass bug-filling against these Packages. Before, it would be
> > nice to have a List of Packages (maybe sorted by Maintainer)
> > which do not call "dh_md5sums".
> > 
> > IMHO Lintian should also check if "dh_md5sums" is called and
> > print at least a warning if this is not the case.
> 
> I agree with you, and I would support mass-filling, if first such a
> list has been published here on d-d, together with the warning of
> mass-filling.

I disagree. Filing bugs on packages not having md5sums _might_ be ok,
altough last time I checked, md5sums were only sugested, nowhere near
a must in policy. Filing bugs based on missing calls to dh_md5sums is
simply stupid. You don't need to build-depend on debhelper to have
md5sums.

Re: Source only uploads? -- Survey evaluation

[Zenaan Harkness]

On Tue, 2003-12-02 at 01:26, Roland Stigge wrote:
> Meanwhile, I strongly suggest the utilization of pbuilder{,-uml} to
> increase quality. Some developers (not the ones who participated here) I
> talked with have never used these tools. Their usage will prevent many
> of those stupid FTBFS bugs.

Does it make sense to have a boilerplate suggestion line suggesting
this, produced by default for all FTBFS emails sent out by bug tracker?

zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: debsums for maintainer scripts

[Henrique de Moraes Holschuh]

On Mon, 01 Dec 2003, Thomas Viehmann wrote:
> Henrique de Moraes Holschuh wrote:
> > On Mon, 01 Dec 2003, christophe barbe wrote:
> > 
> >>Before mass bug-filling, it would be necessary to make it mandatory
> >>which unfortunately is not the case right now afaik. 
> > 
> > 
> > Deployment plan for md5sums everywhere:
> At ~600 affected source packages, this seems hardly feasible.

It is feasible. You just to care about it enough, and you certainly don't
have to do it alone, or in one go.

Otherwise, it simply won't happen, unless about 90% of the packages or so
aready use md5sums.  At that figure, you have some changes of passing a
policy of 'must', and you are guaranteed to get a 'should' to be approved
IMHO.

-- 
  "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

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 07:08, Andreas Tille wrote:
> On Tue, 2 Dec 2003, Zenaan Harkness wrote:
> > I have started a web site at
> >
> > http://debian-enterprise.org/
> Did you
>  apt-get install subproject-howto

I did actually - after your last such recommendation. Double thanks.

> ?  It might help you registering a site under www.debian.org (once its
> services are up again.

Cool. I'll check it out in a day or five :)

> > REALISATION OF GOALS
> >  - meta/ task packages - Debian FLAVOURS (to be implemented,
> >but proposed some time back)
> As I said: At least other people who use the meta package approach inside
> Debian use the term "Custom Debian Distribution" ...

Sorry, I should have updated that line.

I have decided upon the term Custom Debian Distribution for all my own
references. (Note that most other references in [my personal +
debian-enterprise] web pages, the email Subject: and my sig, all refer
to Custom Debian Distribution. Definitely it's a nice term to use.)

> >  - website, support forum?, lists, irc, wiki
> See above.

ta

> In general I like your approach.  You might have a look at
> 
>  http://www.debian.org/devel/debian-jr/ or
>  http://www.debian.org/devel/debian-med/
> 
> and the according wml files in CVS (once this service is up again)

I have spent a little time on those websites, as well as
http://www.debian.org/devel/debian-np/ (non profit) (always more to do
though). In fact, Debian Non Profit is a nice counterpoint to
debian-enterprise, yet I think that technical goals will be more closely
coincident than might at first be obvious :)

Gotta love free software community-based model.

regards
zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: debsums for maintainer scripts

[Thomas Viehmann]

Henrique de Moraes Holschuh wrote:
> On Mon, 01 Dec 2003, christophe barbe wrote:
> 
>>Before mass bug-filling, it would be necessary to make it mandatory
>>which unfortunately is not the case right now afaik. 
> 
> 
> Deployment plan for md5sums everywhere:
At ~600 affected source packages, this seems hardly feasible.
Maybe some of the maintainers (e.g. those using or recommending debsums)
care themselves when being alerted to the fact that some of their
packages don't supply md5sums.

Cheers

T.



pgpFo1mMDCKlI.pgp
Description: PGP signature

Re: XML files referencing DTDs via HTTP

[Brian May]

On Mon, Dec 01, 2003 at 01:51:31AM -0800, Tom wrote:
> That's true.  It can be any string.  The fact that it just happens to 
> look like an HTTP url and DTD is actually at that URL is not part of the 
> standard, AFAIK.

Errr, we are not getting confused??

An example is:

http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; [

According to http://www.w3.org/TR/REC-xml>, the FROMAT IS

doctypedecl:: '

Re: Revival of the signed debs discussion

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [031201 14:40]:
> Instead of keeping extra files with the signature of the deb the
> information could be stored inside the deb itself. Of cause the
> signature can't be contained in the thing being signed. Instead the
> signature would be added to the end or the ar archive and contain
> signatures for all the files (uncompressed?) before it in the archive.
> [...]

In principle I agree with your plan. Just a few suggestions what could
(perhaps?) be also done:

I would like it even more if there would be something along each
package that identifies what was done to the deb-file since creation
(see it as a something like a "passport" or "signature file", where
each entry adds new information to the file).

This would also have the advantage that a system administator could
verify signatures without following who is accepted as a DD, and who
is resigning - without a compromise of the debian server, verifying
any deb with the archive key is enough. If there is however a
suspecion of problems, he could always make stricter checks, without
requiring more infos from the archive. (And of course, any
administrator could also make checks stricter and demand a signature
by a DD plus a signature by the archive script).


More in detail this would mean that after building, the maintainer
signs the md5sums, and a "build this package on ".

After accepted by the archive, the archive script adds a line with
something like "accepted by katie on  because of good signature
of  " to the top, and signs the whole thing.

This has one major drawback: Either the deb-file must be changed
during acceptance to the archive, or the "passport" must reside in an
extra file. (And there is of course a "mixed mode" possible: Extra
file at the moment, and after sarge is released, the files move within
the deb.)


Technical details should IMHO be discussed later, but a sample
passport could look like:

accepted by katie on Mon,  1 Dec 2003 20:34:58 + because of good signature 
of DD, KeyID 0x01234567
build by DD on Sun, 30 Nov 2003 14:34:33 +0100
mgetty-voice_1.1.30-6_i386.deb
450b2b4ffa0be49b43f7358099117f7d control.tar.gz
fb00a05d140ec3e830d6227f3fdd743d data.tar.gz


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Source only uploads? -- Survey evaluation

[Roland Stigge]

Hi Steve,

>> Unfortunately, there wasn't much response to this. Maybe this is 
>> related to the big Debian KO.

> Or maybe because making technical decisions by voting is silly.

At this stage, I personally decided that more official efforts wouldn't
be appropriate just to reflect the community's opinion (at least better
than the preceding discussion) considering that source only uploads were
enabled and disabled in the past without further notice or discussion
otherwise.

Of course, we can take this as a base of further actions.

Finally, the "decision" isn't just "technical".

bye,
  Roland


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

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Chad Walstrom]

On Tue, Dec 02, 2003 at 05:43:21AM +1100, Zenaan Harkness wrote:
>  - GNU ERP software project ?name?

GNU Enterprise (gnue)  http://www.gnue.org/

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgppwhG5wx4GS.pgp
Description: PGP signature

Using selections (was Re: [custom] Custom Debian Distributions)

[Chad Walstrom]

On Tue, Dec 02, 2003 at 05:38:15AM +1100, Zenaan Harkness wrote:
>  * you can't always create a flavour to do what you want

  # From a currently installed machine (or chroot)...
  shell$ dpkg --get-selections > selections
  shell$ vim selections
  shell$ mv selections desktop.selections
  shell$ mailx -s 'my desktop selections' [EMAIL PROTECTED] < \
  > desktop.selections

  # on friend's computer
  shell$ dpkg --get-selections > my.selections
  shell$ diff my.selections desktop.selections
  shell$ sudo dpkg --set-selections < desktop.selections
  shell$ sudo apt-get dselect-upgrade -u

> * improving our mechanisms for supporting "flavours" helps derived
>   distros and their users

I'd be in favor of setting up user's favorite selections lists.  Perhaps
this would be appropriate for community forum sites, such as
DebianPlanet.org?  KISS.  If the solution isn't simple and elegant, it's
probably not ready for prime time.  Distributing selection lists via
forums, websites and the like is an easy way of creating flavors w/o
making structural changes to the Debian project or increasing the
package dependency jungle.

If you find your "flavor" is quite popular and isn't being sufficiently
covered by an existing Debian Subproject, propose a new one.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpe41aXyx4KP.pgp
Description: PGP signature

Re: [debian enterprise] sub-project planning

[Zenaan Harkness]

On Tue, 2003-12-02 at 06:42, Steve Kemp wrote:
> On Tue, Dec 02, 2003 at 06:24:58AM +1100, Zenaan Harkness wrote:
> > And as I put on the web page, a goal of debian-enterprise ("should be",
> > IMHO) to explicitly support *for-profit* organisations. Let's make no
> > bones about it - the goal is to make as much profit as possible, such
> > that we might Do Good Things (TM).
> 
>   I'm agreeing with the ideas of the project, especially availability
>  software and security.  
> 
>   As a related topic I've been working on "bootable Debian", some simple
>  bootable CD-ROM's for different purposes,  a simple Mail server
>  offering POP3/IMAP/SMTP and Spam filtering in a box and a complete
>  Webserver on a CD for example.
> 
>   These sound similar to your turnkey server installaionst you mention.

The two concepts ("flavours"/ custom distros of debian, and [custom]
bootable/ live Debian CDs) have been discussed quite a bit recently on
-devel - see the various threads.

There seems to be a common desire to, where it makes sense at all, make
the tools part of Debian proper, such that these concepts can be readily
"deployed", and Debian the richer for its users.

Seems there are many lines of thought all pretty well aligned at the
moment :)

Inspiring stuff.

Regards
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Chad Walstrom]

On Mon, Dec 01, 2003 at 06:08:28PM +0100, Eduard Bloch wrote:
> Kinda off-topic but nowhere in the discussion the question of checking
> already installed files was adressed and it should be asked:

md5sums and signatures are most useful in the context of installation.
Post-installation, you cannot be guaranteed that an intrusion rootkit
doesn't compromise the md5sum files themselves. Using the installed
*.md5sum files to check the integrity gives you a false sense of
security unless those *.md5sum files are signed or CRC'd as well.
Regardless, using md5sums of selected files does not identify files that
are not part of that set.

A true IDS is needed, such as aide, tripwire, or cfengine to detect
post-installation intrusion.  Tie in aide or tripwire database
checks/updates with the apt.conf "PostInst" option in addition to a
daily cronjon to ensure the database is updated in a timely manner.

For install-time integrity checking, GnuPG signatures or the existing
chain of md5sum and signed Release files should be sufficient without
adding undue complexity.  Integration of debsigs would be a welcome
addition to dpkg.  Folling it's creation, does anyone have a case study
or success story hailing the usefulness of debsigs?

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpNJcsrrHvdf.pgp
Description: PGP signature

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Andreas Barth]

* christophe barbe ([EMAIL PROTECTED]) [031201 20:10]:
> On Mon, Dec 01, 2003 at 07:43:17PM +0100, Michael Ablassmeier wrote:
> > Unfortunately many Maintainers do not use "dh_md5sums" to ship
> > an .md5sums File in their Package(s). This makes it harder to
> > check the already installed Files on a Debian installation.
> > 
> > I think, at least Packages like "dpkg" or "gnupg" should call
> > "dh_md5sums". I was wondering, if it would be usefull to make
> > a mass bug-filling against these Packages. Before, it would be
> > nice to have a List of Packages (maybe sorted by Maintainer)
> > which do not call "dh_md5sums".

> Before mass bug-filling, it would be necessary to make it mandatory
> which unfortunately is not the case right now afaik. 

Severity: wishlist
Where is the problem?


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)

[Andreas Barth]

* Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]:
> I think, at least Packages like "dpkg" or "gnupg" should call
> "dh_md5sums". I was wondering, if it would be usefull to make
> a mass bug-filling against these Packages. Before, it would be
> nice to have a List of Packages (maybe sorted by Maintainer)
> which do not call "dh_md5sums".
> 
> IMHO Lintian should also check if "dh_md5sums" is called and
> print at least a warning if this is not the case.

I agree with you, and I would support mass-filling, if first such a
list has been published here on d-d, together with the warning of
mass-filling.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Anaconda for Debian (and more) now available at platform.progeny.com

[Ian Murdock]

We've completed the migration from internal CVS to external Subversion
and launched an umbrella site to house our various projects, as well as
to detail our larger goals for doing all this. Among other things,
the site contains instructions for how to retrieve our port of
Red Hat's Anaconda installer to Debian and build CDs, as
well as demonstration ISOs that use Anaconda to install sarge.
The site is here:
http://platform.progeny.com/
The site announcement with more information is available here:
http://platform.progeny.com/weblogs/archives/000169.html
For those of you who have no idea what I'm talking about, this is the
continuation of the thread "status of Progeny projects":
http://lists.debian.org/debian-devel/2003/debian-devel-200310/msg01880.html
--
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

Re: Revival of the signed debs discussion

[Andreas Barth]

* Scott James Remnant ([EMAIL PROTECTED]) [031201 18:40]:
> On Mon, 2003-12-01 at 16:26, John Goerzen wrote:
> > Even if the attacker could place a new keyring file in the archive,
> > people verifying signatures on signed .debs would not install it, since
> > it would not have the signature of a developer.

> What defines "the signature of a developer"?  That their key is in the
> keyring, so if a hax0r decided to comprise our keyring and add a key to
> it, there'd be no way to tell that it wasn't a developer's key.

For dpkg on my computer: That the signature is in _my_ _currently_
installed keyring package.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Revival of the signed debs discussion

[Andreas Barth]

* Marc Haber ([EMAIL PROTECTED]) [031201 18:25]:
> On Mon, 01 Dec 2003 15:56:59 +, Scott James Remnant
> <[EMAIL PROTECTED]> wrote:
> >Download the source package components, verify their MD5 signatures
> >against the Sources file, verify the MD5 signature of the Sources file
> >against the Release file and verify that file's GPG signature.  This
> >proves that the package has successfully passed through the ftp-master
> >process and entered the archive.

> The GPG signature on the Release file is automatically generated with
> a key that was stored on one of the compromised boxes. That trust
> chain is thus broken at its very beginning, and unfortunately the
> stable release manager seems to ignore questions on IRC asking for a
> 3.0r2 Release file signed with his personal GPG key.

It is certainly a very good idea to sign the long living Release-files
(also|only) with an off-line key. It would IMHO even better if also
the debs are (better) signed than they are, because double protection
is always better than single protection.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: [debian enterprise] sub-project planning

[David B Harris]

On Tue, 02 Dec 2003 06:27:12 +1100
Zenaan Harkness <[EMAIL PROTECTED]> wrote:
> > Any thoughts on that? Anybody from HP or IBM here want to weigh in?
> 
> My primary thought wrt making money from Free Software - make as much as
> we possibly can - at least that's my goal, so that I can provide for
> myself and my family, and (in the future) work on more Free Software
> projects.

My goals are only to provide something that and end-user can use without
having their vendor tell them they're on their own, no RMAs, no hardware
support, nothing.

Re: Debian Enterprise - a Custom Debian Distribution

[David B Harris]

On Mon, 01 Dec 2003 11:45:35 -0800
Bruce Perens <[EMAIL PROTECTED]> wrote:
> I am still negotiating with the large industry group that approached me 
> about this project. When the price tag is north of $1M, it takes time. 
> If that works out, they would fund 3-5 engineers full-time, plus myself 
> and an admin to work on the aspects of this project that are important 
> to their industry group. And only their industry group. Thus, there is 
> room for participation of a number of vendors and/or industry groups, as 
> well as direct participation by all of the various entities that would 
> participate in Debian.

Are you still on good terms with some people at HP? I don't even think
we need funding, per se. I wouldn't mind getting paid well for the work
I do, but that's a rarity. (Why does money always need to get involved?)

What I'd really like to see is a company providing input, serving as a
central point for customer contact, and above all, actually
*supporting* the use of the end-product. ie: not being hostile to users
who run it, as is so often the case these days. I can't count the number
of times I've heard horror stories from HP customers (and other vendors
as well) about people being unable to RMA hardware because they're using
a decent software bundle that they're familiar with and can maintain, as
opposed to whatever outdated and bastardised crap was included with the
hardware.

Okay, that sort of turned into a rant :) I do apologise, but I'd
desperately like to help dispell the stigma that's associated with
anything non-Red Hat.

Re: Revival of the signed debs discussion

[Andreas Barth]

* John Goerzen ([EMAIL PROTECTED]) [031201 17:40]:
> Even if the attacker could place a new keyring file in the archive,
> people verifying signatures on signed .debs would not install it, since
> it would not have the signature of a developer.

And to be honest: If all debs are signed, and it is easy possible, I
would restrict accepted signatures at my private machine for the
keyring package to James - and let me send a mail if there is a
keyring package signed by any other DD. So, the real danger would be
if James key is stolen.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: (no subject)

[Greg Folkert]

On Mon, 2003-12-01 at 14:11, [EMAIL PROTECTED] wrote:
> To Whom It May Concern;
>  
> I'm sorry but your e mail address was added automatically to by
> list and I do not know who you are?
>  
> Please advise:
> Your company
> What do you do?

This is a Linux Distribution Mailing List for its users. Please remove
us from you mailing list.

The Linux Distribution is Debian. http://www.debian.org

-- 
[EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry


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

Re: [debian enterprise] sub-project planning

[Andreas Tille]

On Tue, 2 Dec 2003, Zenaan Harkness wrote:

> I guess if you're a DD (I'm in the NM-process myself), you can creake
> "official" Debian wiki, etc?
If I'm not completely wrong you do not need to be a DD to get CVS access
to wml pages.

Kind regards

   Andreas.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Andreas Tille]

On Tue, 2 Dec 2003, Zenaan Harkness wrote:

> Seems like now is a good time to start a new thread. Including [custom]
> tag too...
:)

> I have started a web site at
>
> http://debian-enterprise.org/
Did you
 apt-get install subproject-howto
?  It might help you registering a site under www.debian.org (once its
services are up again.
(BTW, the site seems to be unavailable currently ...)

> > This is a extract of my conversation with joey:
Just for the record, we have "two Joeys": Joey Hess and Martin 'Joey' Schulze :)

> REALISATION OF GOALS
>  - meta/ task packages - Debian FLAVOURS (to be implemented,
>but proposed some time back)
As I said: At least other people who use the meta package approach inside
Debian use the term "Custom Debian Distribution" ...

>  - website, support forum?, lists, irc, wiki
See above.

In general I like your approach.  You might have a look at

 http://www.debian.org/devel/debian-jr/ or
 http://www.debian.org/devel/debian-med/

and the according wml files in CVS (once this service is up again)

Kind regards

Andreas.

--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

Re: Debian Enterprise - a Custom Debian Distribution

[Bruce Perens]

Zennan,

Thanks. I can't get to your site at the moment.

I have just closed out some customer work that has been taking up 100%
of my time, and am today writing a manifesto that I will post at
userlinux.com . I will read the debian-devel postings and, hopefully,
your site before I do that.

I am still negotiating with the large industry group that approached me
about this project. When the price tag is north of $1M, it takes time.
If that works out, they would fund 3-5 engineers full-time, plus myself
and an admin to work on the aspects of this project that are important
to their industry group. And only their industry group. Thus, there is
room for participation of a number of vendors and/or industry groups,
as well as direct participation by all of the various entities that
would participate in Debian.

Note there is also a gnUserlinux.org, but RMS objects to that
name - he feels that people will percieve it as an official FSF project
if the GNU comes first. This came as something of a surprise.

    Thanks

    Bruce

Zenaan Harkness wrote:

  This is a brief followup to my earlier queries regarding
debian-enterprise sub project - the new term being Custom Debian
Distribution.

Well, I am slowly building a website for debian-enterprise. This is
something I am personally somewhat passionate about and realised
eventually that I am therefore the person for the job.

Here is the website:

http://debian-enterprise.org/

At the moment any related discussions are being held on debian-devel.

Regards
Zenaan

  

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Henrique de Moraes Holschuh]

On Mon, 01 Dec 2003, christophe barbe wrote:
> Before mass bug-filling, it would be necessary to make it mandatory
> which unfortunately is not the case right now afaik. 

Deployment plan for md5sums everywhere:

1. List packages that do not have a md5sum included.

For every package in the list:
  2. Download the thing, an add a dh_md5sum OR whatever is more in tune with
 the package build system (lots of packages do not use dh_*)
  2a. TEST IT. REALLY.
  2b. Use interdiff or something like that to make sure the only change
  you made was the md5sum thing, and no errors crept in the diff.
  3. Send patch to BTS
  4. Wait 1 month

After that one month:

For every package that the maintainer did not fix the md5sum thing himself:
  1. Upload NMU to biggest delay possible, send email to maintainer,
 and NMU patch to BTS

After the dust settles:

  Propose policy changes. Since well over 90% of the packages should have
  md5sums now, it will probably be accepted.


I am *MOST DEFINATELY NOT* going to do anything like the above. I am just
pointing out what people who _do_ care enough should do to get things fixed.

-- 
  "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

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Michael Ablassmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Dec 01, 2003 at 01:56:09PM -0500, christophe barbe wrote:
> Before mass bug-filling, it would be necessary to make it mandatory
> which unfortunately is not the case right now afaik. 

No, it is not mandatory. However, it would be a nice Wishlist Bug.
So the maintainer can decide, if he want to call this Function or 
not. (was just a suggestion ;-))

bye,
- michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/y5u0EFV7g4B8rCURAgqcAJ9NYg4T9N8aKsm5i/mVXNnqXGqSqACg7TiR
wuxm4wHRY3MQVRHrXcM3Hy0=
=hgyX
-END PGP SIGNATURE-

Re: Source only uploads? -- Survey evaluation

[Andreas Barth]

* Roland Stigge ([EMAIL PROTECTED]) [031201 15:55]:
> On Sat, 2003-11-15 at 14:50, Roland Stigge wrote:
> > [...]
> > Instead, I volunteer to host a small, unofficial and non-anonymous
> > survey to get an impression of the community's opinion. If you are a
> > Debian Developer, please send me a private mail with
> > 
> >   "Source only uploads: Yes"
> > 
> > or
> > 
> >   "Source only uploads: No"
> > 
> > in the subject. At the beginning of December, I will post the results,
> > and if there is any doubt, I will disclose the list of names and votes.
> 
> Unfortunately, there wasn't much response to this. Maybe this is related
> to the big Debian KO.

I didn't see this survey timly (and as I'm not a DD you'd probably
also not interested in my opinion).



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: debsums for maintainer scripts

[Thomas Viehmann]

Michael Ablassmeier wrote:
> IMHO Lintian should also check if "dh_md5sums" is called and
> print at least a warning if this is not the case.
In principle, I argree, but maybe it's better to check for the presence
of an md5sums file than to "force" (haha) people who don't like it to do
this.
Attached is a linda patch that does that. Maybe I'll post a link the
result of the run on my mirror later.

Cheers

T.
diff -urN linda-0.2.23~/checks/controlfiles.py 
linda-0.2.23+/checks/controlfiles.py
--- linda-0.2.23~/checks/controlfiles.py2003-09-23 10:19:19.0 
+0200
+++ linda-0.2.23+/checks/controlfiles.py2003-12-01 20:15:06.0 
+0100
@@ -10,6 +10,8 @@
 norm_control = ('control', 'md5sums', 'conffiles', 'templates', \
 'shlibs')
 control_files = exec_control + norm_control
+   if not common.control_info.has_key('md5sums'):
+   self.signal_error('no-md5sums-control-file')
 for k in common.control_info.keys():
 if k not in control_files:
 self.signal_error('unknown-control-file', [k])
diff -urN linda-0.2.23~/desc/controlfiles.desc 
linda-0.2.23+/desc/controlfiles.desc
--- linda-0.2.23~/desc/controlfiles.desc2003-09-23 10:19:21.0 
+0200
+++ linda-0.2.23+/desc/controlfiles.desc2003-12-01 20:11:42.0 
+0100
@@ -101,3 +101,10 @@
  The maintainer script shown above calls update-rc.d the number of times
  listed above. 
 
+Tag: no-md5sums-control-file
+Type: Warning
+_Description: Package has no md5sums control file.
+ The package does not have a md5sums control file which can be
+ used to verify the integrity of installed package's file via
+ debsums. md5sums files can be created with dh_md5sums.
+


pgpg1JCkDcfXt.pgp
Description: PGP signature

Re: [debian enterprise] sub-project planning

[Steve Kemp]

On Tue, Dec 02, 2003 at 06:24:58AM +1100, Zenaan Harkness wrote:

> Great to hear. I started a web page at http://debian-enterprise.org/.

  Aren't we still waiting for clarification on the use of "Debian"
 in domain names, etc?  As highlighted by the Adamantix name changed?

> And as I put on the web page, a goal of debian-enterprise ("should be",
> IMHO) to explicitly support *for-profit* organisations. Let's make no
> bones about it - the goal is to make as much profit as possible, such
> that we might Do Good Things (TM).

  I'm agreeing with the ideas of the project, especially availability
 software and security.  

  As a related topic I've been working on "bootable Debian", some simple
 bootable CD-ROM's for different purposes,  a simple Mail server
 offering POP3/IMAP/SMTP and Spam filtering in a box and a complete
 Webserver on a CD for example.

  These sound similar to your turnkey server installaionst you mention.

Steve
--
# Debian Security Audit Project
http://www.steve.org.uk/Debian/

Re: [debian enterprise] sub-project planning

[Zenaan Harkness]

On Tue, 2003-12-02 at 05:46, David B Harris wrote:
> On Mon, 01 Dec 2003 13:12:52 -0500
> Andres Salomon <[EMAIL PROTECTED]> wrote:
> > I have discussed this sub-project extensively at Voxel, and we are
> > willing to commit to seeing this idea through - in a manner that allows
> > the Debian community to benefit from resources that we put into it. We
> > are willing to provide developmental resources (Voxel is more than
> > willing to pay me to head up this sub-project), hardware, legal
> > resources, bandwidth, and hosting, with development happening under the
> > Debian moniker.  We are also researching the possibility of 24/7
> > commercial support for enterprise clients, as that is a large part of
> > what companies want (both for technical support, as well as someone to
> > blame when something goes wrong).
> 
> Up until this portion of the email, I was thinking, "oh yeah, this
> sounds good, and get a big company involved too - like HP or IBM."
> 
> Any thoughts on that? Anybody from HP or IBM here want to weigh in?

My primary thought wrt making money from Free Software - make as much as
we possibly can - at least that's my goal, so that I can provide for
myself and my family, and (in the future) work on more Free Software
projects.

> P.S.: I'm willing to put work into the debix/FAI-type stuff.

Heh-heh! Good to hear.

regards
zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: [debian enterprise] sub-project planning

[Zenaan Harkness]

On Tue, 2003-12-02 at 05:12, Andres Salomon wrote:
> I have discussed the idea of a Debian Enterprise sub-project with
> various people, and have concluded that it's a worthy goal.  I have
> listed the technical reasons/goals for this sub-project below.

Great to hear. I started a web page at http://debian-enterprise.org/.

> Initial preparation for Debian Enterprise will take place within Debian
> itself, with the following short-term goals being:

I guess if you're a DD (I'm in the NM-process myself), you can creake
"official" Debian wiki, etc?

> 1. Discussion and work on an "enterprise" kernel.  This will be one of
> the first things I tackle, hopefully w/ input on the requested
> debian-enterprise mailing list (#222359).  The goals for this kernel
> will be inclusion of non-experimental features needed by
> enterprise-level users utilizing Debian in a server environment.  Others
> have suggested simply using a Red Hat kernel; however, Red Hat tends to
> include experimental features, which are a bit too bleeding edge.  I
> would like to see things like:
> 
> A. Clustering (eg, LVS)
> B. Resizable filesystems (device-mapper, ext3online, etc)
> C. Security (pax or exec-shield; pax is preferable, but will
> require modifications)
> D. UML's skas host patch, and so on.  
> 
> Obviously, suggestions are encouraged, but please hold off until the
> debian-enterprise list is created.  If the list cannot be created in a
> timely manner (w/ developer accounts currently locked, this may be an
> issue), I'll host it on a Voxel machine.

Good place to start.

> 2. Given last week's security issues, attention needs to be paid to
> package signatures, as well as authentication methods.  For packages, we
> may want to focus on apt-secure (http://monk.debian.net/apt-secure/);
> I'm not sure the status of it, but it will be something that can be
> discussed.  Of course, this has much interest outside of this
> sub-project; the sub-project will merely help it (and its integration)
> along.  As far as authentication methods, we may want to focus on
> ways to allow out-of-the-box OPIE, SRP, or other ways of PAM
> authentication.  This might be handled w/ a meta-package, for example.
> Again, this needs more discussion.

I'd put security a top priority - hopefully "suggestion C" or something
similar will get implemented soon - see related thread "revival of
signed debs".

> 3. Debian Installer enhancements, and work on getting packages moved
> into testing.  Obviously, these things are useful for all Debian users,
...
> thread brought up things like debix and fai, which would be very
> interesting for this sub-project as well.

agreed

> These are shorter term goals.  Longer term goals include possible
> creation of another branch, security updates on this branch, etc.  I'm
> leaning towards testing snapshots, utilitizing snapshot.debian.net for
> package storage (along w/ security updates for these packages).  The
> goal of this branch will be shorter release cycles (a new release every
> 2-3 months), longer security updates (end-of-life after 2 years, for
> example; 6-8 releases), and focus on only server architectures (m68k
> bugs won't, for example, keep a package out of the distribution;
> enterprise users don't really care about m68k).  

This is an excellent idea. I haven't previously heard of something that
could as easily get around the release timetable problems. Choosing a
(limited) set of architectures will definitely provide a greater
likelihood of meeting release timetables.

> I have discussed this sub-project extensively at Voxel, and we are
> willing to commit to seeing this idea through - in a manner that allows
> the Debian community to benefit from resources that we put into it. We
> are willing to provide developmental resources (Voxel is more than
> willing to pay me to head up this sub-project), hardware, legal
> resources, bandwidth, and hosting, with development happening under the
> Debian moniker.  We are also researching the possibility of 24/7
> commercial support for enterprise clients, as that is a large part of
> what companies want (both for technical support, as well as someone to
> blame when something goes wrong).

Awesome stuff. The great thing about Free Software is that anyone, from
the competant individual to the multinationals, can get involved
providing service where service is wanted, and in the process contribute
back to the community.

> I would like to stress that while Voxel does have commercial motivations
> for getting involved,

And as I put on the web page, a goal of debian-enterprise ("should be",
IMHO) to explicitly support *for-profit* organisations. Let's make no
bones about it - the goal is to make as much profit as possible, such
that we might Do Good Things (TM).

>  the entire sub-project will comply fully with the
> Debian Social Contract, and will not stray far from the Debian's
> official distribution; switching to normal Debian s

(no subject)

[TREXDENIM]

To Whom It May Concern;
 
    I'm sorry but your e mail address was added automatically to by list and I do not know who you are?
 
Please advise:
    Your company
    What do you do?
 
Regards,
 
Don

Re: Revival of the signed debs discussion

[John Goerzen]

On Mon, Dec 01, 2003 at 05:54:17PM +, Scott James Remnant wrote:
> > Please set your Mail-Followup-To accordingly, then.
> > 
> You are now kill-filed, I will not reply to the rest of this post.
> 
> 1) Please re-read the etiquette of the Debian mailing lists as published
>at http://www.debian.org/MailingLists/#codeofconduct

The etiquette as defined in /usr/share/doc/debian/FAQ/ch-support.html
does not mention the issue at all, BTW.

Re: Revival of the signed debs discussion

[John Goerzen]

On Mon, Dec 01, 2003 at 05:54:17PM +, Scott James Remnant wrote:
> On Mon, 2003-12-01 at 17:35, John Goerzen wrote:
> > > No Cc was necessary, I am subscribed to debian-devel.
> > 
> > Please set your Mail-Followup-To accordingly, then.

I guess quibbling about CCs is a great way to disguise the fact that you
just stuck your foot in your mouth about debsigs, eh?

> 1) Please re-read the etiquette of the Debian mailing lists as published
>at http://www.debian.org/MailingLists/#codeofconduct
> 
> 2) Mail-Followup-To is not defined by any standard.

It has long been informal policy, at least, to set Mail-Followup-To for
posting to these lists if you don't want replies.  mutt, which I use,
has no "reply to list" key if you do not set that.  Moreover, MUAs which
aggregate messages from multiple lists into a single folder can make it
very difficult and time-consuming to sort out the assumptions and
preferences for each individual poster in each individual list.  That is
what Mail-Followup-To is for.

There is a standard for Mail-Followup-To.  A quick Google turns it up.
Please see:

http://cr.yp.to/proto/replyto.html

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[christophe barbe]

On Mon, Dec 01, 2003 at 07:43:17PM +0100, Michael Ablassmeier wrote:
> Unfortunately many Maintainers do not use "dh_md5sums" to ship
> an .md5sums File in their Package(s). This makes it harder to
> check the already installed Files on a Debian installation.
> 
> I think, at least Packages like "dpkg" or "gnupg" should call
> "dh_md5sums". I was wondering, if it would be usefull to make
> a mass bug-filling against these Packages. Before, it would be
> nice to have a List of Packages (maybe sorted by Maintainer)
> which do not call "dh_md5sums".

Before mass bug-filling, it would be necessary to make it mandatory
which unfortunately is not the case right now afaik. 

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Cats are intented to teach us that not everything in nature has a
function. --Garrison Keillor

Re: Bug#222076: /etc/init.d/xdm: if stop from within, cannot start again

[Branden Robinson]

tag 222076 + wontfix
retitle 222076 xdm: init script's execution can be terminated prematurely if 
invoke-rc.d run from child process of xdm
thanks

On Sun, Nov 23, 2003 at 05:09:38AM +0800, Dan Jacobson wrote:
> Package: xdm
> Version: 4.2.1-13
> Severity: important
> File: /etc/init.d/xdm
> 
> If one issues
> # invoke-rc.d xdm stop
> from a shell _inside xdm_, PIDFILE is not cleaned up before our shell
> process is killed, therefore any subsequent
> # invoke-rc.d xdm start
> will fail, [even though on the tty it just says 'starting', the bad
> news only going into the log.]
> 
> The user will probably have to nohup the stop command, or do it from
> outside the xdm process tree (e.g. go to tty1)

To be solved properly this would require some sort of signaling
mechanism detacted from most of the normal process hierarchy; say, an
"invoke-rc.dd" (daemon) with which invoke-rc.d communicated.

The problem described is far more general and does not apply only to
xdm.

Tagging wontfix.  Someday this may get reassigned to an init package.

-- 
G. Branden Robinson|Humor is a rubber sword - it allows
Debian GNU/Linux   |you to make a point without drawing
[EMAIL PROTECTED] |blood.
http://people.debian.org/~branden/ |-- Mary Hirsch


signature.asc
Description: Digital signature

Re: [debian enterprise] sub-project planning

[David B Harris]

On Mon, 01 Dec 2003 13:12:52 -0500
Andres Salomon <[EMAIL PROTECTED]> wrote:
> I have discussed this sub-project extensively at Voxel, and we are
> willing to commit to seeing this idea through - in a manner that allows
> the Debian community to benefit from resources that we put into it. We
> are willing to provide developmental resources (Voxel is more than
> willing to pay me to head up this sub-project), hardware, legal
> resources, bandwidth, and hosting, with development happening under the
> Debian moniker.  We are also researching the possibility of 24/7
> commercial support for enterprise clients, as that is a large part of
> what companies want (both for technical support, as well as someone to
> blame when something goes wrong).

Up until this portion of the email, I was thinking, "oh yeah, this
sounds good, and get a big company involved too - like HP or IBM."

Any thoughts on that? Anybody from HP or IBM here want to weigh in?

P.S.: I'm willing to put work into the debix/FAI-type stuff.

[custom] Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

Seems like now is a good time to start a new thread. Including [custom]
tag too...

On Mon, 2003-12-01 at 22:36, Alexander Kitzberger wrote: 
> Hello,
> we and a couple of other linux companies are also thinking this way,
> and we would like also to support a enterprise debian.
> 
> We have the problem that debian has to compete to suse and red hat
> enperprise servers which are certified for oracle, etc.
> 
> We like the idea in having also a enterprise debian to have a 
> alternative, because we like using debian more that other distributions.
> 
> Please inform me if you have any other new regarding this project.

I have started a web site at

http://debian-enterprise.org/

with various ideas. I shall cut and paste into email below for comment.

> I talked to joey a few weeks ago about an ideas that goes into the same 
> direction:
> 
> This is a extract of my conversation with joey:
> --
> Hello Joey,
>  > we and some other linux companies are thinking about some
>  > things for a while. And now the aquisition of suse make this more actual.
>  >
>  > We and the other companies would like to start a new sub-project
>  > under the debian project that may be called "business debian"
>  > or "enterprise debian"
>  >
>  > The aim of this project is to make a homepage (subdomain or subsection
>  > od the debian homepage) to present case studies and reference projects
>  > that service companies like us realized.
> ---

To get the discussion under way, here are the ideas I have collated over
the last few weeks:


Current Ideas List

SCOPE
 - enterprise: company, business, organisation ?
 - for-profit | non-profit ?
 - target users: "enterprise" system administrators
 - clustering ?
 - ISPs ?
 - government bodies ?
 - free software only scope
 - security scope
 - hardware spec scope - do we support 386s?, 486s?
 - deployment scope, eg installations of
   - thin terminals
- pc as - router, bridge
- firewalls
- workstations
- servers - eg. DB, SAMBA, mail, http[s], ftp[s]
 - secure by default installation?

TARGET USERBASE
 - administrators who want to become proficient and knowledgable
 - administrators who are already proficient and knowledgable

SECURITY GOALS
 - what's optional, what's standard

REALISATION OF GOALS
 - meta/ task packages - Debian FLAVOURS (to be implemented,
   but proposed some time back)
 - website, support forum?, lists, irc, wiki
 - documentation
 - tutorials ?
 - base packages (all Debian "required", since we are debian sub, plus
   ssh, evms, kernel-linux-deb-ent, ???)
 - debconf package configurations (with "enterprise" defaults)
 - custom CD, live CD (debix/ knoppix installer discussions on -devel)
 - secure live CD?

DOCUMENTATION
 - one-page (where possible, absolute max of one page) install (apt-get)
   and config guides: the goal being to provide instant recipie/ solution
for the busy (or just learning, or having to deliver RIGHT NOW)
sys admin. !!
 - integration with LDP
 - write a manual (debian admin guide additional chapters) and have it
   printed and distributed in bookstores

COLLABORATION
 - GNU ERP software project ?name?
 - I think working with the RHE Fedora project might be important 1st step
 - red hat stuff - eg. open carpet (ala red carpet)?

LEVERAGE
 - base our initial kernels on the RHE kernels...


Regards
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Michael Ablassmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi Eduard,

On Mon, Dec 01, 2003 at 06:08:28PM +0100, Eduard Bloch wrote:
>  - current md5sums file in control.tar.gz should contain
>checksums of really all files

Unfortunately many Maintainers do not use "dh_md5sums" to ship
an .md5sums File in their Package(s). This makes it harder to
check the already installed Files on a Debian installation.

I think, at least Packages like "dpkg" or "gnupg" should call
"dh_md5sums". I was wondering, if it would be usefull to make
a mass bug-filling against these Packages. Before, it would be
nice to have a List of Packages (maybe sorted by Maintainer)
which do not call "dh_md5sums".

IMHO Lintian should also check if "dh_md5sums" is called and
print at least a warning if this is not the case.

bye,
- michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/y4vFEFV7g4B8rCURAg3/AJ9/V2KIlAGrago22dg27YiJxu4IBACdHDne
TAYfYnISDbUXRkkHuDTGpoA=
=V33R
-END PGP SIGNATURE-

Re: [custom] Custom Debian Distributions

[Zenaan Harkness]

On Tue, 2003-12-02 at 02:46, Anthony Towns wrote:
> So, using my definitions, the following conclusions are (IMO) true:
> 
>   * all flavours are policy compliant
> 
>   * some derived distros might be policy compliant

Do you mean to include, eg. derived distros including non-free software
here, or should we have a separate term for this?

>   * you can't always create a flavour to do what you want
> 
>   * you can always create a derived distro to do what you want
> 
>   * improving our mechanisms for supporting "flavours" helps derived
> distros and their users
> 
>   * we can improve our support for "flavours" by co-opting many of the
> techniques pioneered by derived distros
> 
>   * a derived distro can be an internal Debian project, but won't ever
> be /as/ internal as a flavour
> 
>   * distributing customised Debian distros is not only the way of the
> future, it's the way of the present!

Awesome summary.

That's great - it covers all bases, and it makes sense to me (as someone
who hasn't used the other terms (internal proj, subproj, metadistro,
etc) in the past. I think it would be useful for this to be added to the
Custom Debian Distro wiki (here I think:
http://wiki.debian.net/index.cgi?CustomDebian).

Thanks heaps
Zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Source only uploads? -- Survey evaluation

[Steve Greenland]

On 01-Dec-03, 08:26 (CST), Roland Stigge <[EMAIL PROTECTED]> wrote: 
> 
> Unfortunately, there wasn't much response to this. Maybe this is related
> to the big Debian KO.

Or maybe because making technical decisions by voting is silly.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

[debian enterprise] sub-project planning

[Andres Salomon]

I have discussed the idea of a Debian Enterprise sub-project with
various people, and have concluded that it's a worthy goal.  I have
listed the technical reasons/goals for this sub-project below.

Initial preparation for Debian Enterprise will take place within Debian
itself, with the following short-term goals being:

1. Discussion and work on an "enterprise" kernel.  This will be one of
the first things I tackle, hopefully w/ input on the requested
debian-enterprise mailing list (#222359).  The goals for this kernel
will be inclusion of non-experimental features needed by
enterprise-level users utilizing Debian in a server environment.  Others
have suggested simply using a Red Hat kernel; however, Red Hat tends to
include experimental features, which are a bit too bleeding edge.  I
would like to see things like:

A. Clustering (eg, LVS)
B. Resizable filesystems (device-mapper, ext3online, etc)
C. Security (pax or exec-shield; pax is preferable, but will
require modifications)
D. UML's skas host patch, and so on.  

Obviously, suggestions are encouraged, but please hold off until the
debian-enterprise list is created.  If the list cannot be created in a
timely manner (w/ developer accounts currently locked, this may be an
issue), I'll host it on a Voxel machine.

2. Given last week's security issues, attention needs to be paid to
package signatures, as well as authentication methods.  For packages, we
may want to focus on apt-secure (http://monk.debian.net/apt-secure/);
I'm not sure the status of it, but it will be something that can be
discussed.  Of course, this has much interest outside of this
sub-project; the sub-project will merely help it (and its integration)
along.  As far as authentication methods, we may want to focus on
ways to allow out-of-the-box OPIE, SRP, or other ways of PAM
authentication.  This might be handled w/ a meta-package, for example.
Again, this needs more discussion.

3. Debian Installer enhancements, and work on getting packages moved
into testing.  Obviously, these things are useful for all Debian users,
so development on these may or may not be focused on debian-enterprise.
d-i enhancements might include installation types (similar to redhat's
installer; select server, workstation, etc, and have packages selected
for you), support for enterprise features directly in the installer
(choosing certain features may automatically pull in the
debian-enterprise kernel), and so on.  The previous debian-enterprise
thread brought up things like debix and fai, which would be very
interesting for this sub-project as well.

These are shorter term goals.  Longer term goals include possible
creation of another branch, security updates on this branch, etc.  I'm
leaning towards testing snapshots, utilitizing snapshot.debian.net for
package storage (along w/ security updates for these packages).  The
goal of this branch will be shorter release cycles (a new release every
2-3 months), longer security updates (end-of-life after 2 years, for
example; 6-8 releases), and focus on only server architectures (m68k
bugs won't, for example, keep a package out of the distribution;
enterprise users don't really care about m68k).  

I have discussed this sub-project extensively at Voxel, and we are
willing to commit to seeing this idea through - in a manner that allows
the Debian community to benefit from resources that we put into it. We
are willing to provide developmental resources (Voxel is more than
willing to pay me to head up this sub-project), hardware, legal
resources, bandwidth, and hosting, with development happening under the
Debian moniker.  We are also researching the possibility of 24/7
commercial support for enterprise clients, as that is a large part of
what companies want (both for technical support, as well as someone to
blame when something goes wrong).

I would like to stress that while Voxel does have commercial motivations
for getting involved, the entire sub-project will comply fully with the
Debian Social Contract, and will not stray far from the Debian's
official distribution; switching to normal Debian should be a simple
process of using $APT_FRONTEND to download a group of different
packages. I believe this is the cleanest way to accomplish this (as
opposed to forking).

Comments and suggestions are welcome, but I'm not really interested in
another "Debian already is a server distro" flamewar.



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

Re: Demudi.org

[Zenaan Harkness]

On Tue, 2003-12-02 at 02:06, Andrea Glorioso wrote:
> > "gg" == guenter geiger <[EMAIL PROTECTED]> writes:
> 
> gg> I think  I have to clear  up some  misconceptions here. At the
> gg> beginning   of   this year  I   stopped  packaging  for demudi
> gg> directly, and put all my packaging effort into making packages
> gg> for Debian proper.  I did not say that I am launching a Debian
> gg> multimedia subproject, I  just  said I would  support  whoever
> gg> wants   to do so. (Obviously  nobody  did  yet) So please stop
> gg> referring to me as the driving force behind Debian multimedia,
> 
> I don't think I did - I just said that I discussed this issue with you
> and Marco Trevisani, wrt how  the AGNULA project and debian-multimedia
> could "coexist".  I don't think that's a false statement.
> 
> If somehow my words suggested or implied  that you somehow took on the
> task  of "building" debian-multimedia, that's  just a result of me not
> being a native english speaker.  Sorry if that's the case.

Please don't take offence - it was most likely my comment that started
this. My comment was (slightly misinformed) expression of my desire, in
hindsight.

Anyway, thanks to all for the clarification.

> gg> I am happy that the debian-multimedia list is what it is. A
> gg> list for discussing multimedia applications and its special
> gg> needs for Debian. If Demudi can profit from the work we are
> gg> doing there, then it is good and what I hoped that it would
> gg> be.
> 
> I'd be  happy if the  reverse was  also true, and   that's why I wrote
> those fewlines.  No intent to  give   people more/less recognition
> and/or responsibility than they are aiming for.

Looks like we're all playing the same game. Good to see.

Regards
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: make-kpkg question

[Liberty Young]

On Sat, 2003-11-22 at 09:35, Manoj Srivastava wrote:
> On Wed, 19 Nov 2003 10:46:52 -0700, Liberty Young <[EMAIL PROTECTED]> said: 
> 
> > I'm building kernels for an embedded x86 product, and I'm falling in
> > love with make-kpkg. My only problem is that make-kpkg
> > --added-modules pcmcia-cs kernel_image modules_image doesn't do a
> > depmod on the pcmcia-cs modules against the built kernel. I assume
> > others have not run into this problem as default debian startup
> > scripts do a depmod on the system...however, in an embedded product,
> > every second that can be spared is needed. My goal is to just have
> > make-kpkg build up images that can be just installed on a separate
> > file-system (Compact Flash in my case) without any other work..
> 
>   Umm, it does try a depmod on install:
> if ( -d "/lib/modules/$version" ) {
>   my $ret = system("depmod -a -F $realimageloc/System.map-$version $version");
>  ...
> }
>   $realimageloc is generally /boot. 
> 
>   If you are installing on a chroot, that should work fine, I
>  would think.
> 
> > Am i just missing something here, or is this truley just a 'feature
> > request' bug that should be submitted to the maintainers of
> > make-kpkg?
> 
>   If you provide some more details on how the kernel-imagfe-X.XX
>  .deb is installed, we may be able to help.
> 
>   manoj
> -- 
I'm installing by tarball.  Unfortunately, my embedded OS doesn't have
apt or dpkg (yet). I was thinking that make-kpkg modules_image or
kernel_image would include in the packaged .deb a modules.dep that would
include an updated modules.dep. 
I can see the logic in updating modules.dep during the install process,
and not having a modules.dep that accounts for both in the resulting
.deb from kernel/modules_image. Or is this a policy thing? 

Since it is an embedded distro without dpkg, I HAVE to provide both
tarballs as my main distribution method, along with .deb and .rpm via
alien. 
 
fakeroot alien --to-tgz  kernel-image-X.XX.deb pcmcia-modules-X.xx.deb
after unpacking both tarballs into a ./foo directory, here's what is
"broken" :

$ cd lib/modules/2.4.22-2.3-ts/
$ ls kernel/drivers/net/ppp_async.o
kernel/drivers/net/ppp_async.o
$ grep 'ppp_async' modules.dep 
/lib/modules/2.4.22-2.3-ts/kernel/drivers/net/ppp_async.o: 
/lib/modules/2.4.22-2.3-ts/kernel/drivers/net/ppp_generic.o
$ ls pcmcia/orinoco.o
pcmcia/orinoco.o
$ grep 'orinoco' modules.dep
$


so, modules.dep has ppp_async, but not orinoco, which is from pcmcia-cs
modules (orinoco.o isn't there until i unpack the pcmcia-modules
tarball). 
This means that unless my embedded system does a depmod on bootup, then
things like 'modprobe orinoco' are going to fail. 

Re: Revival of the signed debs discussion

[Scott James Remnant]

On Mon, 2003-12-01 at 17:35, John Goerzen wrote:

> On Mon, Dec 01, 2003 at 05:00:53PM +, Scott James Remnant wrote:
> > No Cc was necessary, I am subscribed to debian-devel.
> 
> Please set your Mail-Followup-To accordingly, then.
> 
You are now kill-filed, I will not reply to the rest of this post.

1) Please re-read the etiquette of the Debian mailing lists as published
   at http://www.debian.org/MailingLists/#codeofconduct

2) Mail-Followup-To is not defined by any standard.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Revival of the signed debs discussion

[Marc Haber]

On Mon, 01 Dec 2003 15:56:59 +, Scott James Remnant
<[EMAIL PROTECTED]> wrote:
>Download the source package components, verify their MD5 signatures
>against the Sources file, verify the MD5 signature of the Sources file
>against the Release file and verify that file's GPG signature.  This
>proves that the package has successfully passed through the ftp-master
>process and entered the archive.

The GPG signature on the Release file is automatically generated with
a key that was stored on one of the compromised boxes. That trust
chain is thus broken at its very beginning, and unfortunately the
stable release manager seems to ignore questions on IRC asking for a
3.0r2 Release file signed with his personal GPG key.

>To verify this was uploaded by a Debian developer, go to
>http://lists.debian.org/debian-devel-changes/ and find the Accepted
>message, verify that message's GPG signature and verify the MD5
>signatures of the files in that against the real files (this contains
>uploaded .deb signatures too).

Unfortunately, changes files generated by buildds and sent to
debian-devel-$ARCH-changes are not archived, so this trust chain only
works for the architecture the original maintainer built on.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Andreas Tille]

On Tue, 2 Dec 2003, Anthony Towns wrote:

> On Mon, Dec 01, 2003 at 10:55:36AM +0100, Enrico Zini wrote:
> > Could you please define precisely "flavours" and "derivative distros"?
>
> Damn, I thought I'd already done that.
The problem is that we want to get those "Custom Debian Distributions"
which where formerly known as "Debian Internal Projects" which are
Debian-Jr, Debian-Med, Debian-Edu, Debian-Np, Debian-Lex and others
(see my talk once people.d.o is up again) under one common thing.
These Custom Distributions use the technique of metapackages and have
common goals and try to develop common technologies.

It would be easy to mention these under one common term for an easy
reference.  In Oslo was a decision to name it "Custom Debian Distribution"
and if we try to speak with each other we have to agree about some
terms.  This thread shows that there is not yet an agreement and this
sucks because we have to explain over and over again what we are talking
about.

For instance we have defined a term "Package Pools" and everybody now
knows what we are talking about ...

Kind regards

  Andreas.

Re: problem with bugs.debian.org

[Thomas Viehmann]

Anthony Towns wrote:
> It should happen with all recently filed bugs; basically the indices
> aren't being updated properly. That's a bit odd, actually, since they're
I actually have a bug submission dated November 29 (MsgID
<[EMAIL PROTECTED]>) that is correctly transmitted to
master.d.o, but I haven't received a confirmation (yet)...
I didn't want to bug anyone about it yet because I did for a list post
which appeared 2 days later... I know they aren't related, but I just
thought I'd wait a little longer this time.

Cheers

T.



pgpSLZNW7xjFb.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Scott James Remnant]

No Cc was necessary, I am subscribed to debian-devel.

On Mon, 2003-12-01 at 16:26, John Goerzen wrote:

> On Mon, Dec 01, 2003 at 03:56:59PM +, Scott James Remnant wrote:
> > Assuming that level of compromise, there's no recent to suspect that
> > they couldn't have free reign adding anything to the archive they
> > wanted.  Signed .debs gain you nothing here.
> 
> If every .deb must be signed by a developer, and we assume that no
> developer leaves secret keys on public machines, then signed .debs does
> save the day.
> 
How?

> Even if the attacker could place a new keyring file in the archive,
> people verifying signatures on signed .debs would not install it, since
> it would not have the signature of a developer.
> 
What defines "the signature of a developer"?  That their key is in the
keyring, so if a hax0r decided to comprise our keyring and add a key to
it, there'd be no way to tell that it wasn't a developer's key.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Revival of the signed debs discussion

[John Goerzen]

On Mon, Dec 01, 2003 at 05:00:53PM +, Scott James Remnant wrote:
> No Cc was necessary, I am subscribed to debian-devel.

Please set your Mail-Followup-To accordingly, then.
> > If every .deb must be signed by a developer, and we assume that no
> > developer leaves secret keys on public machines, then signed .debs does
> > save the day.
> > 
> How?

See the next paragraph.

> > Even if the attacker could place a new keyring file in the archive,
> > people verifying signatures on signed .debs would not install it, since
> > it would not have the signature of a developer.
> > 
> What defines "the signature of a developer"?  That their key is in the
> keyring, so if a hax0r decided to comprise our keyring and add a key to
> it, there'd be no way to tell that it wasn't a developer's key.

You missed the point of the paragraph you quoted.

If I run a machine that checks all incoming packages with debsigs, and
refuses to install those that don't bear a valid signature, it will
refuse to install the new compromised debian-keyring package since it
will not be signed by a key on the existing keyring.

Therefore, my own gpg will never see the attacker's key and will refuse
to install packages bearing its signature.

debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Eduard Bloch]

#include 
John Goerzen schrieb am Monday, den 01. December 2003:

> Debsigs generates its signature by effectively cating the control and
> data components of the ar file together, running that through gpg, and
> storing the resulting signature data in a new component of the ar file.
> I did test this back in 2001 and the code caused no problem for dpkg
> extraction.  In short, if a system does not use debsigs, the whole
> signature is invisible to the system tools.

Kinda off-topic but nowhere in the discussion the question of checking
already installed files was adressed and it should be asked:

are there any plans to store md5sums of the maintainer scripts along
with the current one that are already created for the data.tar.gz
contents? I imagine an attacker to place a time bomb into a prerm script
of an installed package and wait for his next chance.

AFAICS the only way to verify the contents of maintainer scripts
automaticaly is to have the binary package, verify its contents via
.changes or Release/Packages path, extract it and compare the files. Too
complicated.

I would like to see the following things happen:

 - current md5sums file in control.tar.gz should contain
   checksums of really all files
 - a signature of the md5sums file should be stored either in
   control.tar.gz or in the ar file itself
 - new dpkg version should pickup the signature files and store them
   either in /var/lib/dpkg/info or in some alternative directory
 - modify debsums to check the signature as well as maintainer scripts'
   checksums

Any additions, comments, etc.?

MfG,
Eduard.
-- 
Was kann schon auf dem harten Boden der Tatsachen gedeihen.
-- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz)

Re: Revival of the signed debs discussion

[Thomas Viehmann]

John Goerzen wrote:
> On Mon, Dec 01, 2003 at 03:30:58PM +0100, Thomas Viehmann wrote:
> 
>>However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
>>_deb_signature ; md5sum my.deb"  gives two different lines, I'd think
>>signing the individual members of the deb, not the deb in itself is
> 
> 
> Please check out the debsigs package.  I wrote it when I worked at
> Progeny back in 2001, and Branden Robinson maintains it these days.  It
> does exactly that.
Of course! Thanks for pointing this out, my apoligies for not noticing.
(But he promised a man with three noses!)

Yet, it hasn't made it into the standard developer outfit, which seems
to be part of Goswin's point.

Cheers

T.



pgpkbUPN5sAVs.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[John Goerzen]

On Mon, Dec 01, 2003 at 03:56:59PM +, Scott James Remnant wrote:
> Assuming that level of compromise, there's no recent to suspect that
> they couldn't have free reign adding anything to the archive they
> wanted.  Signed .debs gain you nothing here.

If every .deb must be signed by a developer, and we assume that no
developer leaves secret keys on public machines, then signed .debs does
save the day.

Even if the attacker could place a new keyring file in the archive,
people verifying signatures on signed .debs would not install it, since
it would not have the signature of a developer.

All other attacked debs would also fail to install, since they would not
have the signature of a developer.

Re: Revival of the signed debs discussion

[Scott James Remnant]

On Mon, 2003-12-01 at 13:34, Goswin von Brederlow wrote:

> We have no continous trust chain going from the maintainer (also
> meaning buildd + admin), ftp-master.d.o, mirrors to the user. A
> compromised dinstall on master could replace binary uploads with
> trojan versions without any user being able to detect it.
> 
A compromised dinstall on ftp-master could also replace the keyring
package with a new one containing an extra key, used to sign the new
package and any other package they felt like.

Assuming that level of compromise, there's no recent to suspect that
they couldn't have free reign adding anything to the archive they
wanted.  Signed .debs gain you nothing here.


Anyway, I digress from this, I'm replying to point out that we have
exactly the chain of trust you want:


Download the source package components, verify their MD5 signatures
against the Sources file, verify the MD5 signature of the Sources file
against the Release file and verify that file's GPG signature.  This
proves that the package has successfully passed through the ftp-master
process and entered the archive.

To verify this was uploaded by a Debian developer, go to
http://lists.debian.org/debian-devel-changes/ and find the Accepted
message, verify that message's GPG signature and verify the MD5
signatures of the files in that against the real files (this contains
uploaded .deb signatures too).

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Revival of the signed debs discussion

[John Goerzen]

On Mon, Dec 01, 2003 at 03:30:58PM +0100, Thomas Viehmann wrote:
> However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
> _deb_signature ; md5sum my.deb"  gives two different lines, I'd think
> signing the individual members of the deb, not the deb in itself is

Please check out the debsigs package.  I wrote it when I worked at
Progeny back in 2001, and Branden Robinson maintains it these days.  It
does exactly that.

After installing debsigs, please reference the two text files in
/usr/share/doc/debsigs.  debsigs.txt.gz describes how Debsigs works, and
signing-policy.txt.gz provides a draft signing policy I wrote for
Progeny.

Debsigs generates its signature by effectively cating the control and
data components of the ar file together, running that through gpg, and
storing the resulting signature data in a new component of the ar file.
I did test this back in 2001 and the code caused no problem for dpkg
extraction.  In short, if a system does not use debsigs, the whole
signature is invisible to the system tools.

debsigs-signchanges is provided to help with that common case.

Debsigs also provides the ability to add multiple signatures to a .deb.
It is contemplated that this could be used to store, for instance, a
developer signature, an "installer" signature, etc.  The developer
signature would be manually generated, and the installer signature would
be automatically generated.  In this way, an end user could verify that
the .deb did not change since it left the developer's disk -- and that
it is a .deb that actually passed through dinstall.  All of these
verifications are possible with only a keyring.  There is no need to
verify MD5s from other files, etc.  If you have a current keyring, you
could take a random .deb from a floppy and verify its integrity.

Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Anthony Towns]

On Mon, Dec 01, 2003 at 10:55:36AM +0100, Enrico Zini wrote:
> Could you please define precisely "flavours" and "derivative distros"?

Damn, I thought I'd already done that.

Since I evidently didn't, I'm going to spell things out in as much
boring detail as I can. If I don't end up insulting your intelligence,
my apologies. :)

> I see no problems in documenting that the name "Custom Debian" includes
> "Flavours" and "Derivative Distros", and then define what they are.

Okay, IMO there are two techniques worth distinguishing that both aim
to achieve the same goal. That goal is to put a CD (or DVD, or mirror)
in the hands of a user, who can use that CD to get a running, dpkg-based
system that does a particular thing s/he wants, and nothing else. If s/he
wants to setup a multimedia box that records TV programs and acts as an
mp3/ogg jukebox, that's the only sort of software s/he sees -- no web
proxies, no intrusion detection tools, no compilers, no documentation
on setting up RAID arrays and hot-failover. If s/he wants to setup a
fileserver for a small business, s/he might see Samba and Appletalk and
NFS, but there won't be any games or scientific analysis tools available.

The issue isn't so much one of removing those tools entirely -- ideally,
they'll just be an apt-get away anyway -- but of putting the things that
are actually wanted on the first CD (or at least the first few CDs),
and making the installation and configuration process as quick and easy
as possible.

I think "Customized Debian" is a good name for that sort of thing --
it's Debian, but it's customised for particular usage scenarios. If the
usage scenario is common enough, then that's a real win: one person can
do the customisation, and hundreds or thousands can reap the benefits.

> On the other end, I feel that if you see Flavours and Derivative Distros
> as subsets of Custom Debians, then we might have different concepts in
> mind.

Now, there are different possible approaches to this. The most flexible
is to create a "Debian derivative" -- that is, to take Debian, pull
out the bits you like from it, upgrade some things, downgrade others,
recompile some of the stuff that doesn't work quite right, improve a
few things, and add some completely new stuff. That's great, and it's
been demonstrated to work quite well.

The problems are straightforward: if you're writing your own stuff, you
have to manage your own security updates. If you're forked from Debian,
then Debian might make some changes that break compatability with your
stuff, and you might have to think a bit to integrate the changes. You'll
need to find someone to host your images. You can't leverage most of the
Debian infrastructure (BTS, autobuilders in particular, probably).

But there are plenty of benefits too: you don't have to worry about
non-i386 if you don't want. You can set your own policies and not have
to answer to anyone, or convince anyone they're good. You can set your
own schedule. If you've got software that Debian can't distribute (it
costs money per copy or it's internal-use-only, eg), you have to go this
way, to some extent.

So that's what I call a Debian derivative. It's obviously a customised
Debian, but it's customised by taking Debian and adding stuff to it.

While that's by far the most effective way of customising Debian, it's
not the only conceivable way. The other conceivable way to customise
Debian is just to look at all the packages, and rm the ones you don't
care about. If that gives you want you want, you overcome a bunch of
the more annoying shortcomings above: you don't have to do your own
security updates, you don't have to arrange your own hosting, new upstream
releases will be packaged for you without you having to lift a finger,
it'll normally work on all supported architectures without any effort,
and you can file bugs in the BTS without anyone caring that you didn't
install from an *official* Debian CD.

That's what I'm calling a "flavour" of Debian. A different analogy
which makes a little more pedagogical sense is to consider it a "shade"
of Debian -- making the analogy with colours and prisms instead of
taste. Debian, the universal operating system, beams white light at you
all day long, and you put a prism or a filter in its way to get just the
"shade" of Debian that you want. We do this already by choosing which
packages we want on individual systems and setting them up, which is fine;
but what we really want is to be able get a pre-fab filter from the store,
and just plonk it in, so we don't have to bother ourselves all the time.

We can do that to some extent at the moment -- with sections and tasks
and fai classes eg. Which is okay, but it's *far* beneath the level of
coolness provided by Knoppix. And as well, if we get flavours to work
almost as well as Knoppix (creating a livecd that autodetects hardware
and sets you up in a Linux environment with KDE and Gnome and whatever
else, by telling it nothing more than which bits of Debia

Re: problem with bugs.debian.org

[Anthony Towns]

On Mon, Dec 01, 2003 at 01:35:38PM +0100, Stefano Zacchiroli wrote:
> On Mon, Dec 01, 2003 at 12:24:52PM +0100, Oliver Kurth wrote:
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=webfs&arch=source
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=webfs

[or any other url containing "pkgreport.cgi"]

> The same happened to me with a bug reported against pbbuttonsd (don't
> have the number at hand right now). As a personal opinion I think the
> crontabs of the BTS are on some machine still not restored after the
> attack.

It should happen with all recently filed bugs; basically the indices
aren't being updated properly. That's a bit odd, actually, since they're
meant to be updated whenever the bugs are entered into the system
rather than from cron, but that's been a bit flakey ever since it was
implemented so it's no real cause for concern. Adam Heath is a local
admin for the machine hosting bugs.debian.org as well as a maintainer
of the BTS and might have time to look into it before accounts reopen,
but if not, it'll be fixed then. As long as the bugs themselves are
displaying fine (bugreport.cgi / http://bugs.debian.org/nn), no
information is being lost, and the indices can be easily recreated.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgpSx2t7caxFu.pgp
Description: PGP signature

Re: [custom] Re: Custom Debian Distributions (was: Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?))

[Anthony Towns]

On Mon, Dec 01, 2003 at 12:36:37PM +0100, Andreas Tille wrote:
> This is right but under the terms we defined in Oslo also your first
> example belongs to this group.  The problem is that there was no
> official announcement where "Custom Debian" was *defined*.  

These sorts of terms are generally best defined by use, rather than
proclamation, though. "le weekend", anyone? I'm happy to use other terms,
as long as they cover all the different possibilities we want to describe.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004

Re: Demudi.org

[Andrea Glorioso]

> "gg" == guenter geiger <[EMAIL PROTECTED]> writes:

gg> I think  I have to clear  up some  misconceptions here. At the
gg> beginning   of   this year  I   stopped  packaging  for demudi
gg> directly, and put all my packaging effort into making packages
gg> for Debian proper.  I did not say that I am launching a Debian
gg> multimedia subproject, I  just  said I would  support  whoever
gg> wants   to do so. (Obviously  nobody  did  yet) So please stop
gg> referring to me as the driving force behind Debian multimedia,

I don't think I did - I just said that I discussed this issue with you
and Marco Trevisani, wrt how  the AGNULA project and debian-multimedia
could "coexist".  I don't think that's a false statement.

If somehow my words suggested or implied  that you somehow took on the
task  of "building" debian-multimedia, that's  just a result of me not
being a native english speaker.  Sorry if that's the case.

gg> I am happy that the debian-multimedia list is what it is. A
gg> list for discussing multimedia applications and its special
gg> needs for Debian. If Demudi can profit from the work we are
gg> doing there, then it is good and what I hoped that it would
gg> be.

I'd be  happy if the  reverse was  also true, and   that's why I wrote
those fewlines.  No intent to  give   people more/less recognition
and/or responsibility than they are aiming for.

bye,

andrea
--
Andrea Glorioso[EMAIL PROTECTED]
AGNULA/DeMuDi Techie   http://www.agnula.org/
"There's no free expression without control on the tools you use"

Re: RFC: Create d-user-woody, d-user-sarge maillists, deactivate d-user

[Chad Walstrom]

On Mon, Dec 01, 2003 at 03:51:44AM -0800, Hereon wrote:
> Request For Comment on:
>   Enhancing the Debian mailing lists by:
>   Creating debian-user-woody and debian-user-sarge mailing lists,
>   and deactivating debian-user.

Bad idea.  It's generally wrong to assume that more email lists will
result in better coverage.  The more people subscribed to the
debian-user list, the more people there are to answer questions.  If you
split the list, you're not guaranteed that you'll have an even
distribution of email across the new lists.

Because newbies don't give enough details in their emails to debian-user
is not a problem with too many subscribers, it's a problem of
information dissemination.  They aren't paying attention to the
"welcome" message or the info on lists.debian.org.

By adding more lists, it will be confusing to users which one they
should subscribe to.  There is already confusion around the idea of
"Which flavor of Debian to you use?"  Why perpetuate this by making
newbies try to discern which email list they should belong to.  "Join
debian-user," is simple, concise, and understandable.

Finding information on the list is subject to a good indexing
application.  Some MUA's are very good with searching.  You have the
mbox for each email list Debian hosts.  Download the mbox, import it
into your client, and search.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpQdiySvGCir.pgp
Description: PGP signature

Re: Demudi.org

[guenter geiger]

On Mon, 1 Dec 2003, Andrea Glorioso wrote:
> zh> and debian-multimedia (which  I   am on) was kind  of   moving
> zh> forward on the implementation.
>
> I'm not sure what you mean here.
>
> The original idea I discussed  with Guenter Geiger and Marco Trevisani
> was that debian-multimedia would  be a proper Debian subproject, while
> DeMuDi would  somewhat follow different  routes (for example,  we have
> different packages for Jack, albeit based on the great work by Junichi
> Uekawa and Robert Jordens) and we release with a different timetable
> than Debian proper.

I think I have to clear up some misconceptions here. At the beginning of
this year I stopped packaging for demudi directly, and put all my
packaging effort into making packages for Debian proper.
I did not say that I am launching a Debian multimedia subproject, I just
said I would support whoever wants to do so. (Obviously nobody did yet)
So please stop referring to me as the driving force behind Debian
multimedia, because I just do not have the time nor the motivation,
knowledge or talent for doing that.

I am happy that the debian-multimedia list is what it is. A list for
discussing multimedia applications and its special needs for Debian. If
Demudi can profit from the work we are doing there, then it is good and
what I hoped that it would be.

Guenter


> One of the  goals was that  Debian Multimedia and AGNULA/DeMuDi  would
> help each other -  we can definitevely  be better on the  AGNULA side.
> I've posted some ITPs whose  packages I still  didn't have the time to
> polish  enough for them  to  enter Debian,  although  I hope that will
> happen shortly.
>
> Ifyou  want  further information   onAGNULA,  please  refer to
> http://www.agnula.org/.
>
> Any suggestion on  how to cooperate  better is warmly welcome - please
> write directly  to me <[EMAIL PROTECTED]>  or, better yet, to
> [EMAIL PROTECTED]for   "generic"   questionsandto
> [EMAIL PROTECTED] for  technical questions, proposals and/or
> criticisms.
>
> bye,
>
> andrea
> --
> Andrea Glorioso[EMAIL PROTECTED]
> AGNULA/DeMuDi Techie   http://www.agnula.org/
> "There's no free expression without control on the tools you use"
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>