Re: Bug#222730: ITP: zope-groupuserfolder -- group management for Zope

[Andreas Tille]

On Tue, 2 Dec 2003 [EMAIL PROTECTED] wrote:

> This package is an empty dummy package that always depends on a package
> built for Debian's default Python version.
Why that.  It should depend from Debian's Zope version or if explicite
Python dependency is needed for one or the other reason it should depend
from the Python version Zope is dependant from.  This is not automatically
the default Python version.

Kind regards

  Andreas.

Re: popularity-contest

[Petter Reinholdtsen]

[Gürkan Sengün]
> I could not reach [EMAIL PROTECTED] which is mentioned
> on the following page:
> http://people.debian.org/~apenwarr/popcon/

Are you aware that the popcon project are now on alioth?

https://alioth.debian.org/projects/popcon/>

The work stopped up a bit because of the break-in, but we are a small
group maintaining it now.

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

[Graham Wilson]

On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote:
> On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote:
> > The only way to have avoided this kernel vulnerability from day-0 of
> > discovery/fix release would have been to be constantly upgrading to
> > pre-release kernels.
> 
> Yes but also the debian servers would not have been vulnerable if they had
> used 2.4.23. At least not at that point in time.

They also would not have been affected if they were running 2.2.x. Why
don't we just downgrade them all, then?

-- 
gram


signature.asc
Description: Digital signature

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Don Armstrong]

On Tue, 02 Dec 2003, Tom wrote:
> Yes but the attacker did not "steal" the DD's computer.  He rooted it
> remotely.

So the machine is rooted remotely, the DD logs into a debian box even
using our new fangled smart cards, and the attacker still can control
the connection.

In this particular intrusion vector, the use of a smart card merely
means that the attacker has to trojan the ssh binary on the
compromised machine and use it to run a command that opens a shell
under the DD's uid on a non-privledged port, thus circumventing the
smart card in its entirety.

If you log into a machine from a compromised machine using any means I
can forsee today, the attacker can always control the account of the
machine logged into, because the attacker effectively become the user
of the machine.


Don Armstrong

-- 
Tell me something interesting about yourself.
Lie if you have to.
 -- hugh macleod http://www.gapingvoid.com/archives/batch20.php

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote:
> On Tue, 02 Dec 2003, Tom wrote:
> > Yes but the attacker did not "steal" the DD's computer.  He rooted it
> > remotely.
> 
> So the machine is rooted remotely, the DD logs into a debian box even
> using our new fangled smart cards, and the attacker still can control
> the connection.

Not while the smart card isn't inserted.

> 
> In this particular intrusion vector, the use of a smart card merely
> means that the attacker has to trojan the ssh binary on the
> compromised machine and use it to run a command that opens a shell
> under the DD's uid on a non-privledged port, thus circumventing the
> smart card in its entirety.

I don't understand this objection, but it seems valid.  Could you 
explain?

> 
> If you log into a machine from a compromised machine using any means I
> can forsee today, the attacker can always control the account of the
> machine logged into, because the attacker effectively become the user
> of the machine.
> 

Yes, I always warned my employer that all I have to do is own your 
machine before you plug in your smart card, leave a logic bomb to do 
something while you're connected, wait for you to hang up and then 
report back.

But it's all layers, layers, layers.  More layers = better, none is a 
panacea.  Have you ever used smartcards?  I think that the more layers 
the better.

Re: [debian-devel] Re: more details on the recent compromise of debian.org machines

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Matt Zimmerman a következőeket írta:
> On Fri, Nov 28, 2003 at 10:08:45AM +0100, Bernd Eckenfels wrote:
> 
> > In the final announcement I would add also a statement about reducing the
> > number of trust relations between the machines and perhaps limiting shell
> > access.
> 
> It seems fairly clear that this was not an issue because the compromised
> user had accounts on all of the relevant systems.

It occurs to me that
-limiting shell access did save one machine for some time
-this machine had been compromised using a trust relationship
between it and an other compromized debian machine

The question (as ever):
What is the good balance between security (limiting access
and trust relationship in this case), and efficiency of processes
(debian developers' work in this case)?

I demand that the above may or may not mean that trust relationships
and shell access should be restricted, but certainly means that the
possibility and impacts of such measures should be thought about.

-- 
GNU GPL: csak tiszta forrásból

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Don Armstrong]

[NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private
mail, but your e-mail address was munged in some sort of anti-spam
measure, and not trivially un-mungeable. Please consider providing
information on how to demunge it in some X- header, or not using
munging at all.]

On Wed, 03 Dec 2003, Tom wrote:
> On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote:
>> the attacker still can control the connection.
> 
> Not while the smart card isn't inserted.

Well, the DD can't log in without the smart card, so that's clearly a
prerequisite.

>> the use of a smart card merely means that the attacker has to trojan
>> the ssh binary on the compromised machine and use it to run a command
>> that opens a shell under the DD's uid on a non-privledged port, thus
>> circumventing the smart card in its entirety.
> 
> I don't understand this objection, but it seems valid.  Could you 
> explain?

If you have "adjusted" ssh, you don't need to show the compromised
user the output of all the commands that are being run on the other
end of the connection.

> Have you ever used smartcards? 

Unfortunatly, yes.

> I think that the more layers the better.

Sure, I'm just saying that the cost to put > 1000 smart cards with the
requisite hardware in all of the places that DD's log in from doesn't
give us enough extra security to merit the extra cost. Of course, if
someone was to design such a system, work all of the bugs out, and get
a hardware vendor to deploy it to DD's, I wouldn't stand in the way.

[I would personally rather see paired random number generators than
smart cards, but we're a bit too spread out for that to be much of a
reality.]


Don Armstrong

-- 
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
  -- hugh macleod http://www.gapingvoid.com/batch8.htm

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: UserLinux white paper

[Cameron Patrick]

On Wed, Dec 03, 2003 at 08:24:09AM +0100, Bernd Eckenfels wrote:

| > This is the Proprietary software model, with artificial, government
| > imposed (via copyright laws) monopolies, resulting in customer lock-in
| > and price maximization.
| 
| I dont see a monopol, at least no government imposed.

I believe that when Zenaan was saying was the copyright laws /are/ a
government-supported monopoly on distributing a particular creative work
(in this case, a piece of proprietary software).

Cameron.

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote:
> [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into 
> private
> mail, but your e-mail address was munged in some sort of anti-spam
> measure, and not trivially un-mungeable. Please consider providing
> information on how to demunge it in some X- header, or not using
> munging at all.]

Heh.  That's my actual email address.  Fooled ya.

> Well, the DD can't log in without the smart card, so that's clearly a
> prerequisite.

You leave it unplugged until you need it, do your thing, then unplug it.

Sure, I could still infect your toolchain so you unwittingly upload 
trojaned stuff.  But the fact is in this *actual* compromise the 
password was stolen and the hacker worked later at his leisure:
smartcards would have prevented this *actual* incident (but of course 
doesn't prohibit other ways of attack).

If something could have prevented something that actually happened, I 
say go for it.

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote:
> 
> If something could have prevented something that actually happened, I 
> say go for it.

Oh, one last thing: each DD should pay for the device him/her self and 
should be required to fly to meet wherever they can pick them up.  Why 
do you assume somebody has to pay for everything?  What's wrong with 
bearing some of the costs yourself?  This is a big deal.

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

[Artur R. Czechowski]

On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote:
> I agree that smartcards would help a lot.  However as has been previously 
> suggested the cost of 1200+ smart-card readers is probably prohibitive.
What about RSA tokens? This solution does not require any special hardware
to connect on the client side.

Cheers
Artur

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Don Armstrong]

On Wed, 03 Dec 2003, Tom wrote:
> each DD should pay for the device him/her self and should be required
> to fly to meet wherever they can pick them up.  Why do you assume
> somebody has to pay for everything?  What's wrong with bearing some
> of the costs yourself?

Could it possibly be because equipment is expensive and plane flights
around the planet are not cheap?

I know few DDs who are independently wealthy, and frankly, requiring
volunteers to spend large amounts of money so they can volunteer their
time isn't something that we should be doing, nor do I really see the
project as a whole supporting such an action.

Please feel free to produce code and take action to prove me wrong
though.


Don Armstrong

-- 
UF: What's your favourite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: [custom] Debian Enterprise - packages

[Andreas Tille]

On Tue, 2 Dec 2003, John Goerzen wrote:

> First of all.  This is obviously not a Debian projects
I see it clearly as Debian project and can't find the rationale why
you sais that it is _obviousely_ not.
> (since it is not operating within the Debian framework.)
Why.
If I see this right Zenaan is planning the depandencies for the meta packages
he wants to build.  As long as there is no debian-enterprise list created
he has no other chance than using debian-devel to discuss this topics.
It was the same for Debian-Jr, Debian-Med, etc and nobody thought that
this whould not fit into Debian framework.

> I don't see why this then
> necessitates over a dozen threads on debian-devel -- AND why it gets to
> call itself "Debian."  Moreover, I remain unconvinced that there is any
> need to split from the regular Debian framework, especially since it
> seems that all you're doing is removing choices.
... or rather giving suggestions, what might fit well into Enterprise
framework as we did fro children in Debian-Jr.

> (Though I admit I
> killfiled the earlier threads on the topic because they were too
> unwieldy)  Anyway:
Perhaps this is the reason.

> On Wed, Dec 03, 2003 at 02:45:51PM +1100, Zenaan Harkness wrote:
> > * Office Suite - OpenOffice (there's no other near as feature complete)
>
> And OpenOffice is the only one that runs on only two -- yes, two --
> architectures that Debian supports.
Which is a problem for Debian and not for Debian-Enterprise or any other
"Custom Debian Distribution".

> > * Scripting Language - Python (no one will debate this one :)
>
> If you think you can get every large enterprise worldwide to standardize
> on a single scripting language -- much less get even ONE to do that --
> then you will surely be nominated for several nobel prizes.
:)
This is the only part of your mail I do completely agree with.

Kind regards

  Andreas.

Re: [custom] The term "flavor" and encouraging work on Debian

[Andreas Tille]

On Wed, 3 Dec 2003, Fabian Fagerholm wrote:

> In my view (as I said), it would be logical to name a further
> subdivision of that product "flavor".
I like this interpretation of the term flavor and it would be easily applicable
for Debian-Med to flavors like:

- Medical practice
- Medical research
- Microbiology
- Dental practice
- Veterinary medicine
- ...

> Ok. Semantics, of course, but that's what's being discussed here. :)
> I just think "Custom Debian Distribution" is not a very innovative
> phrase, it is too general to instantly give someone an idea of what it's
> about, and on top of all, it's quite long.
ACK.  That's why other people invented terms like "Fedora".  It just
says nothing and so int can't cause false implications.  It has to be
defined precisely before it is a term to work with.

Kind regards

 Andreas.

Re: [custom] The term "flavor" and encouraging work on Debian

[Andreas Tille]

On Tue, 2 Dec 2003, Fabian Fagerholm wrote:

> Actually, I'd like to see the term "Custom Debian Distribution" be set
> aside because a "custom" something is created each time someone modifies
> an original. Debian Enterprise certainly is an original. By the time a
> capable sysadmin has installed it, it will (probably) be "custom".
> ("Custom Custom Debian Distribution", anyone ?)
>
> The term suggests that the distribution is "not-Debian", which is
> unneccessary and confusing.
As non native speaker and also in general I try to avoid joining stupid
naming discussions.  But here is the weak part of the name we have choosen
which has definitely to be clarified in an announcement of those people
who invented the term.

Kind regards

   Andreas.

Re: Revival of the signed debs discussion

[Wouter Verhelst]

On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
> On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote:
> > Joey Hess <[EMAIL PROTECTED]> wrote:
> > > Goswin von Brederlow wrote:
> > >> > dpkg that it is downgrading the package, and a clever attacker might
> > >> > avoid even that.
> 
> > >> How would you avoid it?
> 
> > > Make the replacement package really be a different package entirely, of
> > > a higher version than the package it purports to replace.
> 
> > > I think aj had some more examples along these lines the last time this
> > > came up.
> 
> > I still don't understand how you change the version number (or the
> > package-name) without breaking the signature.
> 
> You change the contents of the compromised Packages file, so that 
> 
> Package: bash
> Essential: yes
> Priority: required
> Section: base
> Architecture: i386
> Version: 2.05b-12
> 
> is accompanied by
> 
> Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb

that information is already embedded in the .deb. Try "dpkg --control
foo.deb; cd DEBIAN; ls".

apt should sanity-check whether that information matches the information
it already has (from, e.g., the Packages file). If not, it should scream
as loud as possible.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Wouter Verhelst]

On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
> Hi, Henrique de Moraes Holschuh wrote:
> 
> > On Tue, 02 Dec 2003, Wouter Verhelst wrote:
> >> So unless you have a suggestion that would solve this particular issue,
> >> I'm afraid this idea won't work in practice.
> > 
> > We could verify if the gpg agent (gpa? I forget the name...) cannot do this
> > over a secure channel. It should be able to, and if not, it can probably be
> > taught to.
> 
> It's not that easy (basically you need to tunnel the actual
> encryprion/signing function, not just the passphrase-getting).
> See ssh-agent as an example.
> 
> The good thing is that people are already thinking about this.
> 
> http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html

Well, implemented as Werner suggests in that message would require me to
send the actual .deb over the line. I won't do that, since I don't have
the bandwidth (or, in many cases, the time to wait for the download to
finish; arrakis runs behind an ADSL line, while quickstep behind my
cable modem. upstream speeds aren't that fast (and I regularly handle
their mails at work)).

As I understand it, an OpenPGP signature is an encrypted hash or
something similar of the actual data. It would be feasible if the
signature algorithm would allow for hashing the data on the remote
machine, and signing that hash locally.

Then again, we could do such things right now. Wouldn't it be more
interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz?
Especially in the case of larger .debs, that would probably reduce the
actual signature size as well...

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

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

[Russell Coker]

On Wed, 3 Dec 2003 20:34, "Artur R. Czechowski" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote:
> > I agree that smartcards would help a lot.  However as has been previously
> > suggested the cost of 1200+ smart-card readers is probably prohibitive.
>
> What about RSA tokens? This solution does not require any special hardware
> to connect on the client side.

What is a "RSA token"?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Revival of the signed debs discussion

[Wouter Verhelst]

On Wed, Dec 03, 2003 at 06:50:09AM +0100, Goswin von Brederlow wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> > How often has this person glance over the results? As I understand debian
> > build daemons run unattended and build continously. Correct me when I am 
> > wrong here.
> > 
> > But if I asume righ, I dont want to lose that processing speed, especially
> > since it can be easyly compensated with "3rd party" timestamps.
> 
> In theory every build log is read. In praxis I believe all buildd
> admins scroll through the log and look for some obvious signs of
> errors before signing. I don't expect them to read a 17 MB logfile
> line by line for example.

Well, actually...

All failed logs are examined to find the cause of the failure and to
decide on further action.

All successful logs get their .changes extracted, signed, and mailed
back. This is often done semi-automatically; in my case, this script is
used:

#!/bin/bash
cat $1 > ~/buildd/orig
cat $1 | sed -e '9,/\.changes\:$/d' -e '/^\*/,$d' > ~/buildd/changes
cat ~/buildd/changes > $1

together with some mutt hooks that allow me to just hit "ryd" for as
many successful logs in my mailbox (and my gpg passphrase on the first
one). IOW, I don't really look at successful messages anymore; if a
build succeeds, it is assumed to be OK (which is why running regression
tests at deb build time is a good idea, and should be done if at all
possible).

They do run mostly unattended, and do build continuously; it's just so
that as-of-yet unsigned packages are put in ~buildd/build instead of
~buildd/upload (they're moved once the signed .changes arrives by mail)

> But even without reading having an actual person handling the signing
> has advantages. In case a buildd is compromised the signing still
> isn't. The attacker can't start and upload 500 backdoor packages
> pretending to be something else without raising red flags.  Also
> failures in the buildd behaviour have to be cought, like building
> empty debs all of a sudden. A quick glance at the package contents
> listed in the build log will detect that.

Even considering the above, this is still true. We keep an eye on our
systems; maintaining an autobuilder is more than just handling its logs.

I regularly have to log in to both machines to fix some issue (once
every week at least); if something "weird" is going on, I'll find out
then. Also, I get logs of all sorts mailed back on a daily and weekly
basis. Those logs I do examine conspiciously.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

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

[Artur R. Czechowski]

On Wed, Dec 03, 2003 at 09:49:21PM +1100, Russell Coker wrote:
> On Wed, 3 Dec 2003 20:34, "Artur R. Czechowski" <[EMAIL PROTECTED]> wrote:
> > On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote:
> > > I agree that smartcards would help a lot.  However as has been previously
> > > suggested the cost of 1200+ smart-card readers is probably prohibitive.
> > What about RSA tokens? This solution does not require any special hardware
> > to connect on the client side.
> What is a "RSA token"?
Device used in some internet banks. You have a device, which has only
chipset, digital pad with on/off switch and display, all embedded in small
case. Authentication is made using C/R algorithm: you receive a number
from system, enter it into token, chipset signs it using stored RSA key, you
get a number from display and use is as a password. 

Cheers
Artur
-- 
[...] jestem wredna, żelazna małpa
/Croolik/

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

[Wouter Verhelst]

On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote:
> On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote:
> > On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote:
> 
> > 
> > The only way to have avoided this kernel vulnerability from day-0 of
> > discovery/fix release would have been to be constantly upgrading to
> > pre-release kernels.
> > 
> > I'm starting to sound like I'm trolling for closed-source development models
> > or something, which is not the case,
> 
> Smartcards would have avoided the Debian compromise: merely having a 
> compromised DD box would have prevented bad guy from getting on the box.

Perhaps. But smartcards have a significant problem in a project such as
Debian:

Are you going to pay for all those smartcards plus their readers?
Including any smartcards for possible future DD's?

If not, I suggest we forget about this, as it won't be feasible.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

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

[Tom]

On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote:
> > What is a "RSA token"?
> Device used in some internet banks. You have a device, which has only
> chipset, digital pad with on/off switch and display, all embedded in small
> case. Authentication is made using C/R algorithm: you receive a number
> from system, enter it into token, chipset signs it using stored RSA key, you
> get a number from display and use is as a password. 

Yeah, these are good: they're cheap and I think it would have been 
effective at preventing this particular incident.  That's an excellent 
idea.

The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Fabian Fagerholm]

On Wed, 2003-12-03 at 12:17, Andreas Tille wrote:
> On Tue, 2 Dec 2003, Fabian Fagerholm wrote:
> > The term suggests that the distribution is "not-Debian", which is
> > unneccessary and confusing.
>
> As non native speaker and also in general I try to avoid joining stupid
> naming discussions.  But here is the weak part of the name we have choosen
> which has definitely to be clarified in an announcement of those people
> who invented the term.

If some of the people who participated in the Debcamp Custom
Distribution BOF (see
http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are
listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was
referenced as one of the driving forces behind the meeting.)

It might be hard, impossible and undesirable to reverse the decision to
use the term. I think the term can be correctly understood if you
present it as I have in some recent postings to this list:

Debian is the super-project.
XYZ is a Debian subproject
that produces a Custom Debian Distribution
with the flavors A, B and C.

A subproject is easily understood: it's an organisational structure.
Basically, it's a group of people working on a subset of Debian. They
coordinate via a web site and in some cases have a special mailing list.

Some subprojects create Custom Debian Distributions for their particular
area of interest. Upon installation of the Custom Debian Distribution,
you can select between a number of flavors that set some defaults to
suit a particular use.

More ideas? Perhaps some of this could be intergrated into the Debian
Subproject Howto as soon as some degree of consensus has been reached.
(I can't find it right now with people.d.o being inaccessible.)
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

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

[Tom]

On Wed, Dec 03, 2003 at 12:10:28PM +0100, Wouter Verhelst wrote:
> 
> Are you going to pay for all those smartcards plus their readers?
> Including any smartcards for possible future DD's?
> 
> If not, I suggest we forget about this, as it won't be feasible.

I don't think the USB models cost that much (maybe $50-$100 ea. in 
bulk).  My badge at Microsoft was my smart card.  The devs themselves 
could pay part of the cost, with perhaps partial donations from a 
corporate sponsor.  I think even a college student could find $50 for 
this.

The other guys suggestion about RSA tokens was better.  I think they are 
probably only $15-$25, because they don't connect to your PC.

Anyway, feel free to forget about it.  It was just a suggestion.

Re: Revival of the signed debs discussion

[Matthias Urlichs]

Hi,

[ I'm Cc-ing Werner Koch on this ]

Wouter Verhelst:
> On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
> > Hi, Henrique de Moraes Holschuh wrote:
> > 
> > > On Tue, 02 Dec 2003, Wouter Verhelst wrote:
> > >> So unless you have a suggestion that would solve this particular issue,
> > >> I'm afraid this idea won't work in practice.
> > > 
> > > We could verify if the gpg agent (gpa? I forget the name...) cannot do 
> > > this
> > > over a secure channel. It should be able to, and if not, it can probably 
> > > be
> > > taught to.
> > 
> > It's not that easy (basically you need to tunnel the actual
> > encryprion/signing function, not just the passphrase-getting).
> > See ssh-agent as an example.
> > 
> > The good thing is that people are already thinking about this.
> > 
> > http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html
> 
> Well, implemented as Werner suggests in that message would require me to
> send the actual .deb over the line. I won't do that,

... and it doesn't make sense, since ...

> As I understand it, an OpenPGP signature is an encrypted hash or
> something similar of the actual data. It would be feasible if the
> signature algorithm would allow for hashing the data on the remote
> machine, and signing that hash locally.
> 
... that would work. It'd probably require a few hooks within GPG
to generate a hash packet / .

> Then again, we could do such things right now. Wouldn't it be more
> interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz?

That makes a lot of sense; you can then compare md5sums independently.
You can't directly compare detached signatures: they're timestamped and
contain random data, AFAIK.

Still, sending the to-be-signed file across the wire doesn't make sense.

> Especially in the case of larger .debs, that would probably reduce the
> actual signature size as well...

?? A hash is a hash, and should be independent of file size.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
REAL PROGRAMMERS don't write in Pascal, Mesa, Ada or any of those other pinko
  computer science languages. Strong typing is for people with weak memories.

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

[Hamish Moffatt]

On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote:
> > What is a "RSA token"?
> Device used in some internet banks. You have a device, which has only
> chipset, digital pad with on/off switch and display, all embedded in small
> case. Authentication is made using C/R algorithm: you receive a number
> from system, enter it into token, chipset signs it using stored RSA key, you
> get a number from display and use is as a password. 

The RSA SecurID tokens are a bit smarter than that; the output for a
given input changes every minute. My employer uses them for remote
access to their intranet; you have a fixed pin number which you enter
into the card to get this minute's (6 digit) password. No reason why the
pin would have to be fixed though.

I have no idea what they cost. Also the newest ones are not exactly fit
for carrying around in your wallet. They last 3 years on internal
batteries.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Revival of the signed debs discussion

[Wouter Verhelst]

On Wed, Dec 03, 2003 at 12:08:10PM +0100, Matthias Urlichs wrote:
> Wouter Verhelst:
> > Especially in the case of larger .debs, that would probably reduce the
> > actual signature size as well...
> 
> ?? A hash is a hash, and should be independent of file size.

Obviously, sorry. I don't know how I got that idea :)

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

Re: configuring lilo on package installation

[Javier Fernández-Sanguino Peña]

On Sun, Nov 23, 2003 at 06:19:39PM +0100, Tobias Grimm wrote:
> Hi!
> 
> I'm working on a nvram-wakeup package for a Debian based VDR 
> distribution (c't vdr). nvram-wakeup needs a special kernel-image, that 
> forces a shutdown on the next reboot. Normally this image is installed 
> to /boot and a new section has to be added to lilo.conf:
> 
> image  = /boot/bzImage.poweroff
> label  = PowerOff
> 
> It wouldn't be a problem to modify the lilo.conf in the maintainer 
> script, but I'm not sure if this is the way this should be done.

Yes it is, it's a policy violation.

> 
> What's the best way to add a section to the lilo.conf during package 
> installation (and remove it when uninstalling)?

If the lilo manager does not provide a script to manage lilo.conf, or does
not provide a way to "hook" things into it (the answer to both question is,
I believe, that it doesn't), IMHO you can only add a debconf note telling
the admin what he needs to do in order to enable the package.

Regards

Javi


signature.asc
Description: Digital signature

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

[Bernhard R. Link]

* Chad Walstrom <[EMAIL PROTECTED]> [031202 18:14]:
> I'm not following your logic, if that's what you call it.  You're saying
> that checking the current filesystem on a daily basis is NOT a good way
> to verify filesystem integrity?

I say it won't give you an real advantage over checking the *.md5sums files.
(The only slight advantage is that it lists all file, but the disadvtage
 that you cannot verify your database).

> Update your system when you introduce a known change (a must).  Check it
> daily (a must).  What is incorrect about this policy?

It will only help you to catch intruders securely, if you your check
involves rebooting daily from a ro-media containing verified kernel and
checksum-utilities. Not to talk about, that a database update should at
least be done after booting from clear mendium without net-access and
checking that the changes are correct.

Otherwise it only catches intruders, hwo are to stupid to cope with system
installed. (Which is the same as with installed .md5sums files)


Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Bug#222450: ITP: audiolink -- makes managing and searching for music easier

[Amit Shah]

Package: wnpp
Severity: wishlist

* Package name: audiolink
  Version : 0.04
  Upstream Author : Amit Shah <[EMAIL PROTECTED]>
* URL : http://audiolink.sourceforge.net/
* License : GPLv2
  Description : makes managing and searching for music easier

 AudioLink is a tool that makes searching for music on your local
 storage media easier and faster. Your searches can include a variety
 of criteria, like male artists, female artists, band, genre, etc.
 .
 It works with MP3 files and creates a mysql database in which it
 stores the information about the music files.
 .

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux magrathea 2.6.0-test11 #1 Thu Nov 27 10:56:43 IST 2003 i686
Locale: LANG=C, LC_CTYPE=C

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

[Marc Haber]

On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
>The RSA SecurID tokens are a bit smarter than that; the output for a
>given input changes every minute. My employer uses them for remote
>access to their intranet; you have a fixed pin number which you enter
>into the card to get this minute's (6 digit) password. No reason why the
>pin would have to be fixed though.
>
>I have no idea what they cost. Also the newest ones are not exactly fit
>for carrying around in your wallet. They last 3 years on internal
>batteries.

I seriously doubt that the server-side software is DFSG-free. The only
Linux Agent that is available from rsa.com is for RedHat 7.3, and I
would be astonished if it were available in source code form.

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

Bug#222592: ITP: sks -- Synchronizing OpenPGP Key Server

[Peter Palfrader]

Package: wnpp
Severity: wishlist

* Package name: sks
  Version : 1.0.5
  Upstream Author : "Yaron M. Minsky" <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/sks/
* License : GPL (parts are LGPL, BSD)
  Description : Synchronizing OpenPGP Key Server

 SKS is an OpenPGP key server that correctly handles all OpenPGP features
 defined in RFC2440 and RFC2440bis, including photoID packages and multiple
 subkeys.
 .
 This key server implementation uses an efficient and reliable reconciliation
 algorithm to keep the database in sync with other SKS servers.  Additionally
 it can both send and receive PKS style sync emails.

Re: Revival of the signed debs discussion

[Matthias Urlichs]

Hi,

Werner Koch:
> There are some minor problems because we don't just sign a hash but
> need to add some more data.  Creating an incomplete hash on the remote
> machine is not the cleanest solution, so I have to come up with a
> better way.
> 
You're the GPG expert...


I'm also a bit concerned about MitM attacks; the hash-or-whatever which
the local side is supposed to sign should probably be encrypted with the
signer's public key, otherwise I can just replace the data packet with
something that ends up signing a totally different file. :-/

In other words, doing this isn't trivial.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Show respect for age.  Drink good Scotch for a change.

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Andreas Tille]

On Wed, 3 Dec 2003, Fabian Fagerholm wrote:

> It might be hard, impossible and undesirable to reverse the decision to
> use the term.
Exactly.

> I think the term can be correctly understood if you
> present it as I have in some recent postings to this list:
>
> Debian is the super-project.
> XYZ is a Debian subproject
> that produces a Custom Debian Distribution
> with the flavors A, B and C.
>
> A subproject is easily understood: it's an organisational structure.
> Basically, it's a group of people working on a subset of Debian. They
> coordinate via a web site and in some cases have a special mailing list.
>
> Some subprojects create Custom Debian Distributions for their particular
> area of interest. Upon installation of the Custom Debian Distribution,
> you can select between a number of flavors that set some defaults to
> suit a particular use.
Thanks for this clarifying words.

> More ideas? Perhaps some of this could be intergrated into the Debian
> Subproject Howto as soon as some degree of consensus has been reached.
> (I can't find it right now with people.d.o being inaccessible.)
You might try

   apt-get {source,install} subproject-howto

Kind regards

   Andreas.

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

[Russell Coker]

On Wed, 3 Dec 2003 23:06, Marc Haber <[EMAIL PROTECTED]> wrote:
> >I have no idea what they cost. Also the newest ones are not exactly fit
> >for carrying around in your wallet. They last 3 years on internal
> >batteries.
>
> I seriously doubt that the server-side software is DFSG-free. The only
> Linux Agent that is available from rsa.com is for RedHat 7.3, and I
> would be astonished if it were available in source code form.

For an initial order of 1200 units and the potential for other larger orders 
they may reconsider this.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

[Hamish Moffatt]

On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote:
> On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
> wrote:
> >The RSA SecurID tokens are a bit smarter than that; the output for a
> >given input changes every minute. My employer uses them for remote
> >access to their intranet; you have a fixed pin number which you enter
> >into the card to get this minute's (6 digit) password. No reason why the
> >pin would have to be fixed though.
> >
> >I have no idea what they cost. Also the newest ones are not exactly fit
> >for carrying around in your wallet. They last 3 years on internal
> >batteries.
> 
> I seriously doubt that the server-side software is DFSG-free. The only
> Linux Agent that is available from rsa.com is for RedHat 7.3, and I
> would be astonished if it were available in source code form.

That's true, but there may be similar technology available from other
companies. I have no idea what the server-side part looks like,
having only been an end user of the token solution.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Hamish Moffatt]

On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote:
> On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote:
> > [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into 
> > private
> > mail, but your e-mail address was munged in some sort of anti-spam
> > measure, and not trivially un-mungeable. Please consider providing
> > information on how to demunge it in some X- header, or not using
> > munging at all.]
> 
> Heh.  That's my actual email address.  Fooled ya.

How about including your full name somewhere in your posts too then?
I find it a bit off-putting to discuss security with someone who's
obscuring their identity.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
> > Hi, Henrique de Moraes Holschuh wrote:
> > 
> > > On Tue, 02 Dec 2003, Wouter Verhelst wrote:
> > >> So unless you have a suggestion that would solve this particular issue,
> > >> I'm afraid this idea won't work in practice.
> > > 
> > > We could verify if the gpg agent (gpa? I forget the name...) cannot do 
> > > this
> > > over a secure channel. It should be able to, and if not, it can probably 
> > > be
> > > taught to.
> > 
> > It's not that easy (basically you need to tunnel the actual
> > encryprion/signing function, not just the passphrase-getting).
> > See ssh-agent as an example.
> > 
> > The good thing is that people are already thinking about this.
> > 
> > http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html
> 
> Well, implemented as Werner suggests in that message would require me to
> send the actual .deb over the line. I won't do that, since I don't have
> the bandwidth (or, in many cases, the time to wait for the download to
> finish; arrakis runs behind an ADSL line, while quickstep behind my
> cable modem. upstream speeds aren't that fast (and I regularly handle
> their mails at work)).
> 
> As I understand it, an OpenPGP signature is an encrypted hash or
> something similar of the actual data. It would be feasible if the
> signature algorithm would allow for hashing the data on the remote
> machine, and signing that hash locally.
> 
> Then again, we could do such things right now. Wouldn't it be more
> interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz?
> Especially in the case of larger .debs, that would probably reduce the
> actual signature size as well...

The size being 132 bytes with only 72 bytes actual payload is small
enough.

But we could change what gets signed: Instead of signing the
control.tar.gz + data.tar.gz cated together the list of md5sums of all
files already present in the deb is signed.

The md5sums list would only be a few hundert bytes so transmitting it
over the network is not a problem. But it would mean one can't sign
buildd uploads offline anymore, or at least not in one go. The deb has
to be signed first and then a new chages file created.

Only transmitting and signing a digest of the deb is allways an option
if it becomes clear that splitting the gpg signing procedure (as
debsisgs uses now) between the remote and local system becomes to
complex. Lets see if a gpg agent can be developed that allows remote
signing without transmitting the deb.

MfG
Goswin

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Thu, Dec 04, 2003 at 12:20:57AM +1100, Hamish Moffatt wrote:
> 
> How about including your full name somewhere in your posts too then?
> I find it a bit off-putting to discuss security with someone who's
> obscuring their identity.

Ha Ha Ha what a joke.  I don't want to be googled for all eternity.

Let me tell you a story about a job I had one time: I worked for a guy 
(in his basement -- don't ask) who bought your personal credit card data 
and other publicly available information.  He would pay about $10,000 or 
$15,000 for lists of ~100,000-200,000 people's data.  My job was to 
datamine it under criteria like:  Give me all the people who make 
between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain 
area, and used their Visa more than 10 times on the boat within the last 
6 months.  We'd rank order the data, apply the filter, and maybe get 
10,000 good names, which he would sell for about $140,000 to a home 
alarm company, who would then call you during dinner. [1]

Another job I had was for a drug testing company.  My job was to write 
the report processing system which would say "You Person X have Tested 
Positive for Drugs A, B, and C and you are fucked."  At one point in 
1994 I had 40,000 people's drug test results on my 486SX-50.  Just for 
grins I did a group by query, grouping drug frequency by a company's SIC 
industry code, and sorting in descending order.  The most frequent 
people to test positive for drugs are construction workers, marijuana 
and cocaine.  The next most frequent are school employees (probably bus 
drivers) testing positive for alcohol.  Everything else was kind of 
evenly distributed.

And you wonder why I am concerned with my identity!!!

[1] I finally told the guy to go pound sand.  I said: "You'd be more 
useful to society if you just grow corn or something."  Doing that type 
of work made me want to slit my wrists.

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> Hi,
> 
> Werner Koch:
> > There are some minor problems because we don't just sign a hash but
> > need to add some more data.  Creating an incomplete hash on the remote
> > machine is not the cleanest solution, so I have to come up with a
> > better way.
> > 
> You're the GPG expert...
> 
> 
> I'm also a bit concerned about MitM attacks; the hash-or-whatever which
> the local side is supposed to sign should probably be encrypted with the
> signer's public key, otherwise I can just replace the data packet with
> something that ends up signing a totally different file. :-/
> 
> In other words, doing this isn't trivial.

Assume you have a secure connection. A ssh connection will be more
secure than the mail being send around now. Anyone could do a MitM
attack on the changes files being mailed, get his own packages changes
file signed, upload the debs and hope noone notices the build didn't
actually upload its deb.

Encrypting the digest with the public key before sending would only
ensure only the recipient can read it, which is rather pointless for
pretty random bits. You could encrypt or sign it with the buildds gpg
key to ensure the origin of the message. Anything short of a
compromised buildd would be save and a compromised buildd would be
fatal whatever method is used.

MfG
Goswin

Re: configuring lilo on package installation

[Goswin von Brederlow]

Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <[EMAIL PROTECTED]> writes:

> On Sun, Nov 23, 2003 at 06:19:39PM +0100, Tobias Grimm wrote:
> > Hi!
> > 
> > I'm working on a nvram-wakeup package for a Debian based VDR 
> > distribution (c't vdr). nvram-wakeup needs a special kernel-image, that 
> > forces a shutdown on the next reboot. Normally this image is installed 
> > to /boot and a new section has to be added to lilo.conf:
> > 
> > image  = /boot/bzImage.poweroff
> > label  = PowerOff
> > 
> > It wouldn't be a problem to modify the lilo.conf in the maintainer 
> > script, but I'm not sure if this is the way this should be done.
> 
> Yes it is, it's a policy violation.
> 
> > 
> > What's the best way to add a section to the lilo.conf during package 
> > installation (and remove it when uninstalling)?
> 
> If the lilo manager does not provide a script to manage lilo.conf, or does
> not provide a way to "hook" things into it (the answer to both question is,
> I believe, that it doesn't), IMHO you can only add a debconf note telling
> the admin what he needs to do in order to enable the package.

One can dpkg-divert lilo with a script that runs the real lilo with an
alternate config file. But thats realy ugly and only works for one
package at a time.

MfG
Goswin

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

[Marc Haber]

On Thu, 4 Dec 2003 00:19:36 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
>On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote:
>> I seriously doubt that the server-side software is DFSG-free. The only
>> Linux Agent that is available from rsa.com is for RedHat 7.3, and I
>> would be astonished if it were available in source code form.
>
>That's true, but there may be similar technology available from other
>companies. I have no idea what the server-side part looks like,
>having only been an end user of the token solution.

I have only taken a perfunctory look at the web site, and the
server-side looks like a PAM plugin for the RSA product.

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: Revival of the signed debs discussion

[Matthias Urlichs]

Hi,

Werner Koch:
> On Wed, 3 Dec 2003 13:26:02 +0100, Matthias Urlichs said:
> > the local side is supposed to sign should probably be encrypted with the
> > signer's public key, otherwise I can just replace the data packet with
> > something that ends up signing a totally different file. :-/
> 
> And if I do that, I could also sign the file right at the remote
> machine because the (or some) signature key must be available over
> there ;-)
> 
Ouch. You're obviously right. :-/

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
The day advanced as if to light some work of mine; it was morning,
and lo! now it is evening, and nothing memorable is accomplished.
-- H.D. Thoreau

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Benj. Mako Hill]

On Wed, Dec 03, 2003 at 01:24:24PM +0200, Fabian Fagerholm wrote:
> If some of the people who participated in the Debcamp Custom
> Distribution BOF (see
> http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are
> listening, perhaps you could elaborate? (Cc'ing Mako Hill since he
> was referenced as one of the driving forces behind the meeting.)
> 
> It might be hard, impossible and undesirable to reverse the decision to
> use the term. I think the term can be correctly understood if you
> present it as I have in some recent postings to this list:
> 
> Debian is the super-project.
> XYZ is a Debian subproject
> that produces a Custom Debian Distribution
> with the flavors A, B and C.

Right.

Your other posts seems well informed. Subprojects is already defined
for us (see http://www.debian.org/devel/ for an example of one
place). Debian-NP is clearly a subproject as is Debian-Med and
the IPv6 project.

If you apt-get install the subproject-howto you will get something
talking *only* about creating a custom Debian-distribution -- not
about creating a subproject for any other sort of work. The folks at
the BOF saw a real lack of interaction between the people making
custom distributions and we attributed this, in part, to the fact that
we didn't have a single concept around which identify and say, "yeah,
that person is doing the same thing as me, we should work together."
The flavors people were not working with the metadistros people and
the subproject people where on their own.

We thought "Custom Debian Distribution" (and a [custom] tag in emails
to -devel until a list is created) both referenced our relationship to
Debian (we're inside) and described what we were trying to do in a way
that was not so restrictive that it couldn't refer to multiple
technologies but not so broad that it would apply to projects with
very different types of goals.

I think we left with the idea that "flavors" or "metadistros" and the
like may still describe *technologies* or methods which one could use
to achieve a Custom Distro.

I think this is in line with what AJ, yourself, and others have said --
which is nice. :)

> More ideas? Perhaps some of this could be intergrated into the Debian
> Subproject Howto as soon as some degree of consensus has been reached.
> (I can't find it right now with people.d.o being inaccessible.)

I think it absolutely should. I also think the HOWTO should be renamed
or expanded in scope to bring it into alignment with the consensus that
seems to be coalescing around these issues.

Regards,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgpOrscPgu7VS.pgp
Description: PGP signature

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Steve Langasek]

On Wed, Dec 03, 2003 at 01:24:50AM -0800, Tom wrote:
> On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote:
> > 
> > If something could have prevented something that actually happened, I 
> > say go for it.

> Oh, one last thing: each DD should pay for the device him/her self and 
> should be required to fly to meet wherever they can pick them up.  Why 
> do you assume somebody has to pay for everything?  What's wrong with 
> bearing some of the costs yourself?

Hahahahahahahaha

Share the crack.


-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote:
> 
> Share the crack.

In my experience kids in college and right out tend to freak out over 
the thought of having to spend a few dollars of disposable income, 
because they don't have any :-)

Hey, laugh if you want, most organizations have dues, it's not 
unprecedented in human history :-)

Re: [RFC] adding system users: which is the best way??

[Andreas Metzler]

Steve Greenland <[EMAIL PROTECTED]> wrote:
[...]
> I think the idea of a namespace for usernames used by packages is a good
> idea, but rather than "debian-", we should take this to the LSB folk, so
> that we can get it done once.

The problem with this is time. I need to add a system-user (for exim4)
_now_. Shall I go for namespace, and if yes which one? _debian-exim,
debian-dexim, DEB-exim?
  cu and- wondering whether he should actually subscribe to another
  ml. -reas

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Graham Wilson]

On Wed, Dec 03, 2003 at 05:42:20AM -0800, Tom wrote:
> Let me tell you a story about a job I had one time: I worked for a guy 
> (in his basement -- don't ask) who bought your personal credit card data 
> and other publicly available information.  He would pay about $10,000 or 
> $15,000 for lists of ~100,000-200,000 people's data.  My job was to 
> datamine it under criteria like:  Give me all the people who make 
> between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain 
> area, and used their Visa more than 10 times on the boat within the last 
> 6 months.  We'd rank order the data, apply the filter, and maybe get 
> 10,000 good names, which he would sell for about $140,000 to a home 
> alarm company, who would then call you during dinner. [1]

So you've aided telemarketers and worked for Microsoft? Is your last
name Darkness, middle name Prince of?

-- 
gram


signature.asc
Description: Digital signature

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

[Fraser Campbell]

On December 1, 2003 07:05 pm, Enrico Zini wrote:

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

Is it free software?  They don't seem to provide a link to the full text of 
their license, it sounds free according to their license summary but I also 
see the statement "Cubit has only a very small yearly license fee and no 
purchase cost".

-- 
Fraser Campbell <[EMAIL PROTECTED]> http://www.wehave.net/
Georgetown, Ontario, Canada   Debian GNU/Linux

Bug#222630: ext2 is the wrong default for partconf/create-filesystem

[Gleydson Mazioli da Silva]

I think the reason for that is because on old BF days disk space was expensive 
(so 
lost 32MB for a journal file ou more than that would be a considerable lost).

Joey Hess <[EMAIL PROTECTED]> escreveu em Sun, 30 Nov 2003 21:43:54 -0500:

> Package: partconf
> Severity: normal
> 
> Most users will want a journaling filesystem, and ext3 would be a good
> choice for the default filesystem type, but the current default, ext2,
> is not a very good choice. I suggest to s/2/3 in the Default field of
> the partconf/create-filesystem template.
> 
> -- System Information:
> Debian Release: testing/unstable
> Architecture: i386
> Kernel: Linux dragon 2.4.22 #1 Sun Oct 12 15:11:10 EDT 2003 i686
> Locale: LANG=en_US, LC_CTYPE=en_US
> 
> -- 
> see shy jo
> 


---
Gleydson Mazioli da Silva
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Negligência: Nome que se dá, no colégio, à burrice das crianças ricas.


pgpquQdgm9Jab.pgp
Description: PGP signature

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Wed, Dec 03, 2003 at 09:06:07AM -0600, Graham Wilson wrote:
> 
> So you've aided telemarketers and worked for Microsoft? Is your last
> name Darkness, middle name Prince of?

Satan fell because he wanted to know.  So do I.
I'm a contrarian.  I believe the opposite of whatever I'm confronted 
with at the moment.

Evil is when you look around your life and say: "man, I gotta get some 
new friends." :-)

exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

Hi,

as co-maintainer for the exim4-packages, I have noticed an issue with
dselect. Currently, exim4 is the default MTA, and exim4, exim4-base,
exim4-config and exim4-daemon-light are Priority: important, while
exim4-daemon-light provides mail-transport-agent. The exact package
dependencies can be seen in the archive.

This causes dselect to install exim4-base and exim4-config on a system
that has some other (non-exim) MTA installed, which is a bad thing.

I have discussed this with Andreas, and we didn't find a solution,
since the exim4-packages need to be installed and configured in a
certain order to be operational. Both of us are not adept in package
dependency declaration, so I would like to ask the experts how to
solve this problem.

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: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote:
> as co-maintainer for the exim4-packages, I have noticed an issue with
> dselect. Currently, exim4 is the default MTA, and exim4, exim4-base,
> exim4-config and exim4-daemon-light are Priority: important, while
> exim4-daemon-light provides mail-transport-agent. The exact package
> dependencies can be seen in the archive.

What are they, exactly, and why are they that way?

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


pgphcwC6tQbhF.pgp
Description: PGP signature

Two different libpng2_1.0.12-3.woody.3_i386.deb?

[Santiago Vila]

file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb
wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file
wget -q -O 2.deb http://security.debian.org/pool/updates/$file
diff 1.deb 2.deb

Binary files 1.deb and 2.deb differ

How could this happen? Should I worry about it?

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Andreas Metzler]

On Thu, Dec 04, 2003 at 02:15:30AM +1000, Anthony Towns wrote:
> On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote:
>> as co-maintainer for the exim4-packages, I have noticed an issue with
>> dselect. Currently, exim4 is the default MTA, and exim4, exim4-base,
>> exim4-config and exim4-daemon-light are Priority: important, while
>> exim4-daemon-light provides mail-transport-agent. The exact package
>> dependencies can be seen in the archive.
 
> What are they, exactly, and why are they that way?

exim4 is a metapackage that depends on the other three and is not hit by
the problem. The rest is a straighforward chain.

With "-->--" as "depends on":

daemon -->-- -base -->-- -config.

other possible dependencies would be:
daemon -->--  -config -->-- -base
or
daemon -->-- -base
   `>--  -config

The daemon-packages provide/conflict/replaces MTA.

The main point is that the daemon is started by its own postinst
and therefore it requires ATM -base to be unpacked (init-script) and
-config to be configured.

Afaict starting/stopping the the daemon in its own postinst/prerm is
really the only correct thing to do as it needs to be restarted when
only daemon is upgraded or when you exchange daemon-light for
daemon-heavy.
 cu andreas

Re: development environment question

[John Smith]

On Wed, 2003-12-03 at 18:36, bruce wrote:
> hi...
> 
> I was talking with Ian Murdock yesterday, and he suggested I pose the
> question to this group.
> 
> We're interested in creating a development environment that would allow open
> source applications to be created. The development environment would go
> beyond simply providing project management functions (ala sourceforge.net)
> but to actually allowing developers to build/create/test their applications
> within our network. Users would be able to add/modify applications on the
> test servers to suit their needs. Such a network would have to be carefully
> developed, given the inherent security issues.
> 
> The issue we're facing, is how would you go about constructing such an
> environment. Does anyone have any pointers to information/sites regarding
> this issue? Does anyone have expertise regarding the
> construction/development of this kind of environment?
> 
> I kind of thought that given what Debian has put together with it's
> development environment, that there might be people on this list who might
> be able to provide some  pointers.
> 
> All reasonable pointers/assistance will be helpful.
> 
> Thanks
> 
> Bruce Douglas
> [EMAIL PROTECTED]
> (925) 866-2790
> 
> 

Hi Bruce,

I don't want to disappoint you, but as with all IT projects, 
you need to specify a very specific goal that you want to achieve. 
Your goal, "allow open source applications to be created" and "allowing
developers to build/create/test their applications within our network.
Users would be able to add/modify applications on the test servers to
suit their needs" doesn't sound very aimed toward something.

Given the requirements for application development, a lonely
place for writing and a clean environment for testing, I don't think
you are going to achieve much. Separated testing environments with
free access to the internet to the outside, look like an awfully
inviting target for people with not so nice intentions (spammers, virus
distributers, port scanners etc.)

Good luck, hope you make something of your idea.

Sincerely,

Jan.

Re: [custom] Debian Enterprise - policies

[Andres Salomon]

On Wed, 03 Dec 2003 15:01:09 +1100, Zenaan Harkness wrote:

> (Really should read ahead further ... here are more, and all laid out
> together)
> 
> * DFSG Free Software only (I know this one will get debated, but this is
> the whole point of Debian Enterprise - if you want proprietary software,
> go buy Red Hat or SUSE/Novell).
> 

This goes without saying.  If it's under the Debian name, it should comply
w/ the various Debian policies.


> * Specifically targetting For-Profit entities (vs Debian-NP)
> 

Is this really a goal?  While we're not specifically targeting non-profit
entities, we're not going to exclude them, either; especially if they have
infrastructure similar to a standard for-profit company.  Non-profits need
their oracle, too.  ;)


> * 100% Debian (Social Contract, DFSG, policies + procedures)
> 
> * LSB compliance


I think LSB compliance is one of the most important things listed (aside
from standard stuff like policy compliance).  We want commercial
software vendors to supply binaries that adhere to the LSB; whether
distributed in deb, rpm, or tarball format.  Furthermore, we want to
convince commercial software vendors that working within the LSB is more
important than working within Debian.  A company may certify their
software to work w/ DE (or a DE flavor); we should convince them to
certify software to work w/ all LSB-compliant distributions.  This allows
companies to not limit themselves to DE, or a subset of DE flavors, but
all of Debian (and other LSB-compliant distributions).




> 
> * "Official" statement as to support of Freedesktop.org standards
> 
> * Common Criteria ("not until we're big enough")
> 
> * OpenCOE ("the COE folks had to wedge _apt_ into Red Hat to get it to
> work to their satisfaction")
> 
> * "we have a FIPS 140 certification for OpenSSL"
> 
> * Other standards ??

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

[Bernd Eckenfels]

On Wed, Dec 03, 2003 at 01:54:22PM +1100, Matthew Palmer wrote:
> >Nov 28  22:39  Linux 2.4.23 released
> >   ^
> 
> Bernd is correct, though - if the machines had been running 2.4.23, they
> wouldn't have been vulnerable.  The fact that it was impossible to do so
> doesn't enter into the equation when you're working from blind assertions. 
> 

Hehe, well I am sorry. I had the impression 2.4.23 was older. Should have 
checked my facts.

BTW: I do have checked the kernel version of the major distros, all ship
newer kernels than debian (if you look at the upstream version). However I do 
not know
how reliable dostrowatch is, for comparision.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

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

[Andreas Schuldei]

* Russell Coker ([EMAIL PROTECTED]) [031203 04:03]:
> I have sent a message to Werner asking if the GPG smart-card device could be 
> re-implemented with a USB interface.  I think that a USB dongle with GPG 
> technology would be a good option as most developer's machines already have 
> USB support.

as discussed in depth in an earlier c't magazine (german) usb is
not a save bus to use for security relevant applications, since
it allows for recording and backplaying of command sequences.

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Mon, 1 Dec 2003 19:22:44 -0200, Henrique de Moraes Holschuh <[EMAIL 
PROTECTED]> said: 

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

Before we make such a push, we should at least ensure that it
 is something we really want to do. I think locally generated
 checksums are a better solution.

manoj
-- 
There are three schools of magic.  One: State a tautology, then ring
the changes on its corollaries; that's philosophy.  Two: Record many
facts. Try to find a pattern.  Then make a wrong guess at the next
fact; that's science.  Three: Be aware that you live in a malevolent
Universe controlled by Murphy's Law, sometimes offset by Brewster's
Factor; that's engineering.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: [custom] Debian Enterprise - packages

[Chris Halls]

On Wed, 2003-12-03 at 05:49, John Goerzen wrote:
> > * Office Suite - OpenOffice (there's no other near as feature complete)
> 
> And OpenOffice is the only one that runs on only two -- yes, two --
> architectures that Debian supports.

You missed two.  OOo is available on i386, powerpc, sparc and s390.

Chris

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Darren Salt]

I demand that Tom may or may not have written...

> On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote:
>> Share the crack.

> In my experience kids in college and right out tend to freak out over the
> thought of having to spend a few dollars of disposable income, because they
> don't have any :-)

Some of us have to *buy* them before we can spend them ;-)

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Oh, sarge too...

This was the most unkind cut of all.

Re: [custom] Debian Enterprise - flavors

[Mark Ferlatte]

Zenaan Harkness said on Wed, Dec 03, 2003 at 02:58:18PM +1100:
> Flavours (and sub-flavours/ tasks/ yadda) is as good a place to start as
> any. So here are some proposed flavours:
> 
>  - Enterprise (base packages and more "neutral" config)
>  - Enterprise Desktop - with sub-flavours of:
> - Secretary Desktop
> - Presentation Client (OO Presenter, multimedia, flash)
> - Developer Desktop (all build-depends of all flavours, as a start)
> 
>  - Enterprise Fileserver
>  - Enterprise Webserver
>  - Enterprise Auth Server
>  - Enterprise Departmental Server (combines File, Web + Auth)
> 
>  - Enterprise Firewall
>  - Enterprise SCM Server
>  - Enterprise Router
> 
>  - Enterprise Thin Client

Something to keep in mind that most of the above could be handled by exactly
the same software loadout.

For example:  There is no difference between Desktop, Fileserver, Webserver,
Auth Server loadouts that matters; you just turn off the services by default
and let the customization process turn on the services that matter for that
role.  It doesn't matter if the webserver has openoffice installed; it's just a
few bits on disk.

It might be worth reading
http://www.infrastructures.org/papers/bootstrap/bootstrap.html before getting
flavour happy.

M


pgpduCDZGTL4W.pgp
Description: PGP signature

Re: [custom] The term "flavor" and encouraging work on Debian

[VEROK Istvan]

On Wed, 3 Dec 2003, Andreas Tille wrote:
> On Wed, 3 Dec 2003, Fabian Fagerholm wrote:
>
> > In my view (as I said), it would be logical to name a further
> > subdivision of that product "flavor".
> I like this interpretation of the term flavor and it would be easily
> applicable for Debian-Med to flavors like:
>- Medical practice
>- Medical research
[snip]

Just a suggestion on naming:

Due to the unclear connotations, there is a great deal of confusion over
the terms "internal project", "subproject", "flavor", "custom Debian
distribution" and the like.  To clarify my own thinking, I started using
just "subset" and "mutation" instead.

To my mind, the difference is whether a given collection of packages aims
to be straightforwardly upgradable to a full Debian (IOW, whether it can 
peacefully coexist with any number of packages from Debian proper).  If
yes, it's a subset.  If no, it's a mutation.  Debian-Jr, Debian-NP,
Debian-Lex, Debian-Med are all subsets.  Adamantix and Knoppix are
mutations.

Subsets can also have subsets, or a subset may even come from the
confluence of other subsets, so there is no need to name one level a
"custom Debian distro" and another level a "flavor".

My EUR 0.02,
Istvan

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Mon, 1 Dec 2003 18:08:28 +0100, Eduard Bloch <[EMAIL PROTECTED]> said: 

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

umm, not if it is automated at install time, when the package
 is present already.

> I would like to see the following things happen:

> - current md5sums file in control.tar.gz should contain checksums of
>really all files

Hard to do for conffiles. Now, if the md5sums were generated
 at install time, you could checksum my locally modified conffile
 (even if I did not accept the maintainers changes). The md5sums
 stored for conffiles currently are rarely any good, since the files
 are often modified by the admin.

> - a signature of the md5sums file should be stored either in
>control.tar.gz or in the ar file itself

So you have to download the package itself to check the
 contents of the md5sum fule? Why not generate the md5sums at this
 point anyway?

> - new dpkg version should pickup the signature files and store them
>either in /var/lib/dpkg/info or in some alternative directory

Or you could sign the newly generated md5sum files at install
 time, complete with the checksums of the locally modified conffiles,
 and not have to depend on knowing the key of the persons producing
 the Packages file.

> - modify debsums to check the signature as well as maintainer
>scripts' checksums

ok.

manoj
-- 
I have a theory that it's impossible to prove anything, but I can't
prove it.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: UserLinux white paper

[Bernd Eckenfels]

On Wed, Dec 03, 2003 at 04:36:18PM +1100, Zenaan Harkness wrote:
> How many financials implementations are ultimately needed - really only
> one, perhaps customized for vertical markets.

A healthy market requires competition. And different companies have very
different needs. The IT Infrastructure is indeed the only last field where
Enterprises can differ, today.

> This is the Proprietary software model, with artificial, government
> imposed (via copyright laws) monopolies, resulting in customer lock-in
> and price maximization.

I dont see a monopol, at least no government imposed.

> This is not a properly free market economy. The monopolies are
> artificially imposed, not natural.

Well, I dont think it is correct to asume that Free Software can be the
model for all Software Business. Someone has to pay for the work needed,
after all. And somebody has to get payed, which is more important! (Yes I
known, Free is Free as in free speach). Free Software is one possible business
model, as long as it is not priceless. Customer lock-ins are more uncommon with
Free Software (however, even if you have the source code to your FI, you wont
change your software rovider easyly).

> Free Software clearly and evidently redifines *within the current
> (legal, financial) system* the way to a Free Market Economy.

Hmm.. the above sentence looks good, I wonder what it means?

> We will see profits of some ISVs fall, we will see others disappear
> altogether. We will see new organisations take hold in this new free
> market - predominantly services-based organizations.

It does not look that way, if you look on the current market, but I might be 
wrong.

Looking at the figures of a typical ISV, most of them (unless they manage to
do a large share if OEM business) earn more than 50% of their money by
services. It is already the case, that service is the main focus in the
business. You do not sell software, you solve problems. (You sell solutions,
like Ted put it)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: [custom] The term "flavor" and encouraging work on Debian

[Fabian Fagerholm]

On Wed, 2003-12-03 at 01:32, Zenaan Harkness wrote:
> > Debian is the super-project.
> > Debian Enterprise is a Debian Subproject that creates
> > a Custom Debian Distribution,
> 
> Subproject and custom debian distribution, here, are the same thing. No
> point "officially" having two terms. CDD is a term that I think is
> intended to be a little more expansive than subproject, so I think
> that's more applicable for this "level" of naming...

When the term "Custom Debian Distribution" was chosen, the rationale was
that there is a need to differentiate between subprojects that aim to
create a special version of Debian, and subprojects that do other
things, such as IPV6 or the technical committee.

So, I interpret that as meaning that a subproject is an abstract,
organisational thing (how it manifests itself is another matter) and a
Custom Debian Distribution is the concrete product put together by a
subproject.

In my view (as I said), it would be logical to name a further
subdivision of that product "flavor".

> Correct depending on your view. But it is also true that Debian
> GNU/Linux is an original, of which Debian Enterprise is a customization
> - and this is the useful distinction in this case.

Ok. Semantics, of course, but that's what's being discussed here. :)
I just think "Custom Debian Distribution" is not a very innovative
phrase, it is too general to instantly give someone an idea of what it's
about, and on top of all, it's quite long.

Compare with "package pool" -- anyone with decent knowledge of the
English language, and who knows what a "package" is, will instantly see
the idea. I think "flavor" fits into the same category.

-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> On Wed, Dec 03, 2003 at 03:17:20AM +0100, Goswin von Brederlow wrote:
> > What the admins signature can gives us is a trusted timestamp and
> > another pair of eyes reading the changes files.
> 
> Well, a trusted timestamp can be added/required by a third party. No need to
> bother a build admin with signing of packages he cannot verify.
> 
> Just make a small web service which is receiving an
>  string and answer with a signed timestamp. There
> are even services like that out there on the net.

If there is no person sitting there signing it manually its useless.
The buildd admin is already signing every changes file before upload
so he is the logical person for signing debs too.

> > Don't get me wrong, I'm all for an gpg key on the buildd to sign every
> > deb. Not as replacement to at least one person glancing over the
> > result but as an extra measure.
> 
> How often has this person glance over the results? As I understand debian
> build daemons run unattended and build continously. Correct me when I am 
> wrong here.
> 
> But if I asume righ, I dont want to lose that processing speed, especially
> since it can be easyly compensated with "3rd party" timestamps.

In theory every build log is read. In praxis I believe all buildd
admins scroll through the log and look for some obvious signs of
errors before signing. I don't expect them to read a 17 MB logfile
line by line for example.

But even without reading having an actual person handling the signing
has advantages. In case a buildd is compromised the signing still
isn't. The attacker can't start and upload 500 backdoor packages
pretending to be something else without raising red flags. Also
failures in the buildd behaviour have to be cought, like building
empty debs all of a sudden. A quick glance at the package contents
listed in the build log will detect that.

MfG
Goswin

Re: [custom] Debian Enterprise - packages

[Andres Salomon]

On Wed, 03 Dec 2003 14:45:51 +1100, Zenaan Harkness wrote:

> As per the recommendations from Bruce Perens' User Linux paper
> http://userlinux.com/white_paper.html, this thread is to discuss the
> applications within the bounded set of Debian Enterprise/ User Linux.


I think discussing the favorite applications, at this point, is a bit
premature.  Debian Enterprise (DE) should be concentrating on the
framework that will make flavors possible.  There is much that remains to be
done on the technical level (kernels, a distribution that is up-to-date
enough that companies will _want_ to use it, an installer, etc).  Deciding
what applications to supply isn't of much use right now (especially given
the rate of development of some; mozilla-firebird may be a good choice
now, but what about when epiphany or another alternative becomes the
better browser?).

Remember the original goals that DE is attempting to solve. 
Current Debian-using companies must maintain their own package backports,
kernels, and so on.  Deciding what browser we will default to, while
possibly helping in standardization, is a long ways off.  In order for DE
to become useful, we must cater to companies (not the other way around). 
Thus, we should build out the infrastructure enough so that DE, by itself,
is installable and useable.  At that point, we can start worrying about
what flavors will contain what software.


> 
> The bounded set will depend on the flavour. So first comes proposed
> flavours (and sub-flavours/ tasks/ yadda) - see previous email/ thread.
> 
> Here are some initial (obviously debatable and incomplete) selections to
> start out the bounded-apps conversation:
> 
> * Web Browser
>   - Mozilla-Firebird
> I've used Mozilla, Galeon in its day, more recently Epiphany, and the
> last few months Moz-Firebird. It is simply the simplest (and in my
> opinion best) of the crop.
> 
> * Web Server - Apache 2.0 (let's get with the times)
> 
> * Open SSH Implementation - OpenSSH (much more active that gnu version)
> 
> * Office Suite - OpenOffice (there's no other near as feature complete)
> 
> * Scripting Language - Python (no one will debate this one :)
>  - I have never used, only read (plenty) about Python, and I'm not
> personally too sure about this white space thing, but from what I hear
> about it (quite consistently) eventually feeling more "natural" than
> anything else, I am inclined to believe this really is the case. My
> experience with Java (after C/C++) was sort of like that, and if Python
> is more so, then I think it could be closest to the next VB replacement

Install Images

[Tom Badran]

Is there anywhere i can download debian-installer beta images (im getting a 
new laptop tommorow), prefereably with support for reiserfs filesystems? 
Gluck still isnt working and i cant seem to find mirrors anywhere.

Thanks

Tom

-- 
 ^__^| Tom Badran
 (oo)\__ | Imperial College
 (__)\   )\/\| Department of Computing
||w || ---
|| ||| Using Debian SID


pgpg1D2FLjlBS.pgp
Description: signature

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

[Goswin von Brederlow]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Tue, Dec 02, 2003 at 02:10:56PM +, Jonathan Dowland wrote:
> > On Mon, Dec 01, 2003 at 07:06:41PM -0500, Joey Hess wrote:
> >  
> > > Similarly, to check the build depends of a source package file:
> > >   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm
> > 
> > Should this be the job of apt-get? Fetching a list of build-depends is a
> > similar job to that performed by apt-cache for other fields. I always
> > associate apt-get with installing and removing packages.
> 
> Yes, and "apt-get build-dep somesourcepackage" does install the
> necessary build-deps, so this fits right in.

"apt-get build-deb foo-version.dsc" would be nice when building a
package with changed build-depends (compared to what Sources.gz
lists).

Most of the time the ones mentioned in Sources work though and debuild
will show the rest.

MfG
Goswin

Re: INSTALL-REPORT

[Thomas Wana]

On Wednesday 03 December 2003 19:33, Joshua Kwan wrote:
> On Wed, Dec 03, 2003 at 09:22:14AM +0100, Werner Wobrowsky wrote:
> > Debian Installer sarge-i386-bussinescard.iso, httP://freedesktop.or/
>
> Cool, but...
>
> > FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003
> > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEW
>
> I didn't know the sarge ISOs supported Debian/FreeBSD. :)
> Wrong dmesg?

Hehe not only that, he seems to have marked the whole dmesg
and pasted it into the shell again, producing lots and lots
of shell error messages. Funny thing :-) that's why it is a
good idea to double-check the stuff you mail, especially when
it goes to a high volume mailing list ... you could look a 
bit stupid.

Tom

P.S.: in the pasted part:

$ FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003
FreeBSD: not found

:-)

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Sebastien Bacher]

"AKL. Mantas Kriauciunas" <[EMAIL PROTECTED]> writes:

> Hi,
>
> Debian has a usability problem - it's hard to start lots of programs, 
> installed from debian packages, because simple users just can't find
> them in menu.
> Standart debian menu entry isn't good solution for user-friendly
> desktops, like Gnome and KDE, because debian menu isn't intuitive (for
> example there are no icons for categories) and there are no possibility
> to translate debian menu entry.
>
> Solution is to add freedesktop.org standartized menu entry for programs,
> which could be started from menu (for example there is no meaning to
> start apt-get tool from menu). Then users of modern desktops will be
> happy, because they can easily find how to start installed applications
> - menu entries will be localized and will be in right place.
>
> Why I'm writing this letter instead simply filling bugs on packages?
> 
> ...
>
> Maybe debian developers should improve debian package making standards
> (Debian policy) and recommend to add Gnome/Kde menu entry for all packages,
> which have Debian menu entry ? Then maintainers will include .desktop
> files, at least after bugreports :)

I'm not sure that's a good idea. I'm using Gnome and I'd like to keep a
simple applications' menu, not having hundred entries like in my
debian's menu. Having too many entries in a menu is an usability problem
imho (it's very annoying to search an item in the middle of long
menus). If you are using non KDE/Gnome apps you should perhaps add some
launchers in the desktop for them ?

I've added the gnome/kde in the Cc: field because I think it's rather a
desktop's problem than a mentors/devel problem.


Cheers,

Sebastien Bacher

Re: Install Images

[Tom Badran]

On Wednesday 03 December 2003 18:12, Andreas Metzler wrote:
> http://freedesktop.org/~daniel/d-i/
>   cu andreas

You star ;)

Thanks

Tom

-- 
 ^__^| Tom Badran
 (oo)\__ | Imperial College
 (__)\   )\/\| Department of Computing
||w || ---
|| ||| Using Debian SID


pgpQ49PglrOcI.pgp
Description: signature

Re: Revival of the signed debs discussion

[Werner Koch]

On Wed, 3 Dec 2003 12:08:10 +0100, Matthias Urlichs said:

>> signature algorithm would allow for hashing the data on the remote
>> machine, and signing that hash locally.
>> 
> ... that would work. It'd probably require a few hooks within GPG
> to generate a hash packet / .

Since I moved my actual development to faster machines I now always
need to copy the tarballs to the box where I can sign them and this is
not very convenient.  Obviously, I thought about such a solution too.

There are some minor problems because we don't just sign a hash but
need to add some more data.  Creating an incomplete hash on the remote
machine is not the cleanest solution, so I have to come up with a
better way.

  Werner

-- 
Werner Koch  <[EMAIL PROTECTED]>
The GnuPG Expertshttp://g10code.com
Free Software Foundation Europe  http://fsfeurope.org

Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?

[Jeroen van Wolffelaar]

On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote:
> file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb
> wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file
> wget -q -O 2.deb http://security.debian.org/pool/updates/$file
> diff 1.deb 2.deb

> Binary files 1.deb and 2.deb differ

$ dpkg -x 1.deb 1 ; dpkg -x 2.deb 2
$ diff -ur 1 2
Binary files 1/usr/share/doc/libpng2/changelog.Debian.gz and
2/usr/share/doc/libpng2/changelog.Debian.gz differ
$ zdiff -qs */usr/share/doc/libpng2/changelog.Debian.gz
Files - and /tmp/changelogDebian.gz.10985 are identical

So, only the gzip compression on the changelog is different... which
means that both packages are created independently from the same source,
with the same resulting binaries etc, only apparently using different
versions of gzip and/or different default options for gzip.

> How could this happen? Should I worry about it?

Very strange, maybe it has something to do with them being security-team
NMU's, one is build by security team, the other by the maintainer.

Should you worry? I don't know, depends on wether it's normal that two
different builds circulate on offical archives...

--Jeroen

-- 
Jeroen van Wolffelaar
+31-30-253 4499
[EMAIL PROTECTED]
http://Jeroen.A-Eskwadraat.nl

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Wed, Dec 03, 2003 at 06:43:18AM +0100, Goswin von Brederlow wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
> > 
> > > But this kind of tampering _can_ be checked by apt before installing
> > > the deb simply by adding a signature verifyer into the
> > > DPkg::Pre-Install-Pkgs config option, the same mechanism
> > > apt-listchanges already uses to display only the new section of the
> > > changelog.
> > 
> > Indeed, apt can do a lot better, and is very close to doing so. See #203741.
> 
> The assumption was that the archive was compromised but the Release.gpg
> file changed and resigned.

Who was assuming this?  At any rate, protecting the secret key is of course
the weakest link in any public key cryptosystem, and I don't see what that
has to do with apt.

> #203741 is about checking the
> Release.gpg chain of trust or is there more hidden in all the mails.

Yes, that is what it is about.

> Did the BTS reoder the mails, there don't seem to follow a locigal
> discussion. Haven't bothered to check the timestamps though.

Messages from discussions in other fora (including private mail) were later
copied to the BTS.

-- 
 - mdz

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Zenaan Harkness]

On Wed, 2003-12-03 at 20:15, Herbert Xu wrote:
> AKL. Mantas Kriauciunas <[EMAIL PROTECTED]> wrote:
> > 
> > Solution is to add freedesktop.org standartized menu entry for programs,
> > which could be started from menu (for example there is no meaning to
> > start apt-get tool from menu). Then users of modern desktops will be
> > happy, because they can easily find how to start installed applications
> > - menu entries will be localized and will be in right place.
> 
> If the Debian menu system can't represent what you want, then we should
> either extend it so that it does, or get rid of it.  It makes no sense
> to support two sets of menu entries throughout the distribution.

I agree. I would like to see .desktop standard adopted. There have been
a few threads I have seen so far, and there seems to be some level of
resistance to the idea.

I think if "too many applications in menu" or "wanting simple menu" is a
different problem entirely. Once you know where to find apps, you still
have too many. At the moment it's doubly complex, and that's plain
silly!

imho of course
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://homepages.ihug.com.au/~zenaan/
* PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-03 12:24, Fabian Fagerholm wrote:
> On Wed, 2003-12-03 at 12:17, Andreas Tille wrote:
> > On Tue, 2 Dec 2003, Fabian Fagerholm wrote:
> > > The term suggests that the distribution is "not-Debian", which is
> > > unneccessary and confusing.
> >
> > As non native speaker and also in general I try to avoid joining stupid
> > naming discussions.  But here is the weak part of the name we have
> > choosen which has definitely to be clarified in an announcement of those
> > people who invented the term.
>
> If some of the people who participated in the Debcamp Custom
> Distribution BOF (see
> http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are
> listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was
> referenced as one of the driving forces behind the meeting.)

hm, I've added a definition to the wiki:

  A Custom Debian Distribution (CDD) is a version of Debian that is tailored   
  for a particular situation/target group out-of-the-box. 

  Any changes necessary to Debian to support this particular situation/target  
  group arge merged back into Debian whenever possible, improving Debian as a  
  whole.

- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/zdCV5ihPJ4ZiSrsRAsbLAJ9DdvJr/UQyZlIA0hAQgfu9b/gdowCglNOb
vJDtVz2E2aHumHDpKmxSjHc=
=CIIJ
-END PGP SIGNATURE-

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Matthias Urlichs]

AKL. Mantas Kriauciunas wrote:

> Herbert Xu: "Please discuss this on debian-devel before filing further
> bugs."

IMHO, there's no need to discuss this to death -- .desktop files make
sense, therefore packages should supply them. There's no sane way to ask
maintainers to do so except to file bugs, therefore bugs should be filed,
and that's all there is to it.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
The seven deadly sins ... Food, clothing, firing, rent, taxes, respectability
and children.  Nothing can lift those seven milestones from man's neck but
money; and the spirit cannot soar until the milestones are lifted.
-- George Bernard Shaw

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Anthony Towns  writes:

> On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
> > You change the contents of the compromised Packages file, so that 
> > Package: bash
> > is accompanied by
> > Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb
> > which contains a perfectly valid .deb file, signed by a DD, that has
> > nothing whatsoever to do with bash.
> > AFAIK, apt does not sanity check the relationship between package names
> > and filenames (and it's not obvious that this should be part of its
> > responsibilities), and dpkg only gets a list of .debs to install once
> > they've been downloaded.
> 
> Problem is that apt runs:

Not realy a problem, a benefit in this case.

>   # dpkg -i vulnerable-ident-server_1.0-1_i386.deb
>   # dpkg --configure bash
> 
> the latter will generally give you an error, and for remote exploits,
> just unpacking the vulnerable software isn't enough. It's probably fine
> for local exploits, but you'd have to be on your toes.

You get an error. Its a bit late in the process as it is now but for
me red flags would rise, sirens start screaming, the internet
connection starts a 60 second hardware cut countdown :)

> Getting apt to downgrade a package you've already got installed is more
> straightforward; although "apt-get dist-upgrade; apt-get dist-upgrade"
> will keep trying to download the same deb then.

Yeah, as shown version mismatches don't show up suspiciously. One has
to read the output carefully to detect those. Fat chance when doing a
dist-upgrade of 300 debs.

That is what you ment, a older package claiming to be newer, right?

> Getting apt to upgrade a package you've already got installed to something
> newer that's vulnerable isn't detectable, but will usually need a newer
> libc6, which is a good warning sign.

If you upgrade you probably want a newer version. Making sure you
don't install a vulnerable version (be it a faked or real package
doesn't much matter) is your own job. Faking the newest version
to be an even newer, not yet existing, version might throw people off
thinking a DSA has already been fixed or prevent future fixes from
getting installed though.

I wrote a little script that checks what apt things its installing
against what the control files of the debs say. I will test it with
some more fakes and then file it in the BTS.

MfG
Goswin

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Thu, 4 Dec 2003 04:21:55 +1000, Anthony Towns
 wrote:
>I'm going to ignore the -config package, since it's not really part of
>the problem.

Is it?

>Okay, so you want to say:
>
>   * any exim4-daemon package should only be installed when exim4-base
> is already installed and setup
>   * exim4-base and shouldn't be installed when another MTA
> is installed
>   * exim4-base shouldn't be installed when exim4-daemon isn't going
> to be installed

Yes. Additionally, the three points hold for exim4-config as well.

>Ideally you'd have a dep loop here: exim4-daemon deps exim4-base and
>vice-versa. There are two options that can make that work, one is a
>Pre-Depends: (avoid if possible, but maybe not unreasonable),

Do we need consensus on -devel to have two binary packages built from
the same source declaring a pre-dependency?

>the other
>is to ensure that exim4-base (and config) is "configured" first, which
>can be done by having them not have a postinst script. That mightn't be
>good enough.

Both -base and -config have non-trivial postinst scripts.

>If those solutions aren't possible, then you can have exim4-base installed
>without an exim4 daemon. To avoid having another MTA installed, you have
>to have a Conflicts: m-t-a. You thus also have to have a Provides: m-t-a.
>But then you have to provide /usr/sbin/sendmail, which means you need
>a daemon installed.
>
>So you're back to needing the circular dependencies.

Right.

>Personally, I'd suggest not having the separate -config package; and
>letting sites do their own exim configurations manually, rather than by
>creating a replacement -config package.

The way -config does the configuration is something that is questioned
by a lot of people. Most conservative eximists hate the configuration
being split out in several files, and having the separate -config
package allows people to throw away the entire -config magic.

This is something I would hate to give up.

>If that's really out of the question, and the -config or -base package needs
>a postinst atm, a Pre-Depends is probably the best option.

Which package should then pre-depend on which other package?

Greetings
Marc, really appreciating your help

-- 
-- !! 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: debsums for maintainer scripts

[Manoj Srivastava]

On Mon, 1 Dec 2003 17:12:36 -0500, christophe barbe <[EMAIL PROTECTED]> said: 

> 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?).

Because it buys little security wise? Because there are
 solutions one can put in place today that offer better coverage than
 in package md5sums?

manoj
-- 
In an age when the fashion is to be in love with yourself, confessing
to be in love with somebody else is an admission of unfaithfulness to
one's beloved. Russell Baker
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: [RFC] adding system users: which is the best way??

[Zenaan Harkness]

On Thu, 2003-12-04 at 01:51, Andreas Metzler wrote:
> Steve Greenland <[EMAIL PROTECTED]> wrote:
> [...]
> > I think the idea of a namespace for usernames used by packages is a good
> > idea, but rather than "debian-", we should take this to the LSB folk, so
> > that we can get it done once.
> 
> The problem with this is time. I need to add a system-user (for exim4)
> _now_. Shall I go for namespace, and if yes which one? _debian-exim,
> debian-dexim, DEB-exim?

This might be pointing out the obvious, but anyway:

If nothing else, perhaps email a freedesktop list to get a tentative/
quick discussion of the topic - put some suggestions up there if you
want to pre-empt particular convention, and tell them what you chose
after a few days. Pre-existing usage (if you're the first), especially
as the result of discussion with the relevant people, will add something
to the decision process, hopefully toward not having to make changes in
the future.

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://homepages.ihug.com.au/~zenaan/
* PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Bug#222730: ITP: zope-groupuserfolder -- group management for Zope

[Nicolas Ledez]

Le Wed, Dec 03, 2003 at 08:58:19AM +0100, Andreas Tille a écrit :
> On Tue, 2 Dec 2003 [EMAIL PROTECTED] wrote:
> 
> > This package is an empty dummy package that always depends on a package
> > built for Debian's default Python version.
> Why that.  It should depend from Debian's Zope version or if explicite
> Python dependency is needed for one or the other reason it should depend
> from the Python version Zope is dependant from.  This is not automatically
> the default Python version.
Oups, it's a real package, but I made a copy-paste too fast.

Updated description :

Description: Add group management to zope
 GroupUserFolder is a kind of user folder that provides a special kind
 of user management.
 Some users are "flagged" as GROUP and then normal users will be able to
 belong to one or serveral groups.

-- 
Nicolas Ledez - Virtual Net (www.virtual-net.fr)
80, avenue des Buttes de Coesmes - 35700 RENNES
tel: +33 2 23 21 06 32 - fax: +33 2 99 38 16 85


pgphfEsDtRkDo.pgp
Description: PGP signature

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Wed, 3 Dec 2003 06:54:29 -0800, Tom Ballard  <[EMAIL PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote:
>>
>> Share the crack.

> In my experience kids in college and right out tend to freak out
> over the thought of having to spend a few dollars of disposable
> income, because they don't have any :-)

Guess what the median age of a Debian developer is.

> Hey, laugh if you want, most organizations have dues, it's not
> unprecedented in human history :-)

Volunteer organization have dues? And what services would
 Debian provide, pray, apart from the priviledge of working without
 pay?

manoj
-- 
"I don't know what you mean by 'glory'," Alice said. Humpty Dumpty
smiled contemptuously.  "Of course you don't -- till I tell you.  I
meant 'there's a nice knock-down argument for you!'" "But glory
doesn't mean 'a nice knock-down argument'," Alice objected. "When I
use a word," Humpty Dumpty said, in a rather scornful tone, "it means
just what I choose it to mean -- neither more nor less." "The question
is," said Alice, "whether you can make words mean so many different
things." "The question is," said Humpty Dumpty, "which is to be master
-- that's all." Lewis Carrol, "Through the Looking Glass"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: OT: Smartcards and Physical Security

[Tom]

On Wed, Dec 03, 2003 at 09:26:15AM -0600, Manoj Srivastava wrote:
>   Guess what the median age of a Debian developer is.

Don't know, don't care.

>   Volunteer organization have dues?

Yes, I don't know what planet you're from, but on this planet the 
Rotarians, Kiwanas, Civitans, Knights of Columbus, United Way, Red 
Cross, Freemasons, NAACP, and Jerry's Kids all collect money from their 
members.  You still feeling superior?

Re: OT: Smartcards and Physical Security

[Tom]

On Wed, Dec 03, 2003 at 09:28:30AM -0600, Manoj Srivastava wrote:
>  Sender: Tom Ballard <[EMAIL PROTECTED]>

Yeah, somebody else pointed that out.  It's bullshit that mutt was doing 
that to me.  My /etc/email-addresses:
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: [EMAIL PROTECTED]
#otheruser: [EMAIL PROTECTED]
tom: Tom <[EMAIL PROTECTED]>

So I thought I was covered, and my .muttrc never showed it.  I fixed
it.

Like I said, I never thought I'd have to lie to Linux, but there you 
are.

Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]

[Tom]

On Tue, Dec 02, 2003 at 05:34:05PM -0800, Don Armstrong wrote:
> On Tue, 02 Dec 2003, Tom wrote:
> > I think the DD's should seriously think about requiring smartcards.
> > It would have prevented the proxmiate cause of our recent troubles.
> 
> Smartcards are not a magical panacea either. The problems associated

No, they're not.  Security is all about layers of defense.

> with them aren't too terribly different from those associated with
> keys or other forms of physical security, notably, that they can be
> stolen, or the output from them duplicated. Refer to the ongoing saga
> between DirectTV and satelite pirates for a trivially applicable
> example.

Yes but the attacker did not "steal" the DD's computer.  He rooted it 
remotely.  It is true that a shitty smartcard which is only dumb storage 
for a private key is no better than storing your keys on an USB keyring.

Good smartcards never transfer the key off the card.  The smart card can 
be compromised itself true.  Repeat: Security is about layers of 
defense.  Multiple things have to be compromised.

> 
> From my perspective, Smartcards do little to raise the bar. They
> merely move the bar sideways.

You're wrong.  They're better.

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Wed, Dec 03, 2003 at 05:49:20PM +0100, Andreas Metzler wrote:
> exim4 is a metapackage that depends on the other three and is not hit by
> the problem. The rest is a straighforward chain.
> 
> daemon -->-- -base -->-- -config.
> other possible dependencies would be:
> daemon -->--  -config -->-- -base
> or
> daemon -->-- -base
>`>--  -config
> The daemon-packages provide/conflict/replaces MTA.

On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote:
> This causes dselect to install exim4-base and exim4-config on a system
> that has some other (non-exim) MTA installed, which is a bad thing.

I'm going to ignore the -config package, since it's not really part of
the problem.

Okay, so you want to say:

* any exim4-daemon package should only be installed when exim4-base
  is already installed and setup
* exim4-base and shouldn't be installed when another MTA
  is installed
* exim4-base shouldn't be installed when exim4-daemon isn't going
  to be installed

Ideally you'd have a dep loop here: exim4-daemon deps exim4-base and
vice-versa. There are two options that can make that work, one is a
Pre-Depends: (avoid if possible, but maybe not unreasonable), the other
is to ensure that exim4-base (and config) is "configured" first, which
can be done by having them not have a postinst script. That mightn't be
good enough.

If those solutions aren't possible, then you can have exim4-base installed
without an exim4 daemon. To avoid having another MTA installed, you have
to have a Conflicts: m-t-a. You thus also have to have a Provides: m-t-a.
But then you have to provide /usr/sbin/sendmail, which means you need
a daemon installed.

So you're back to needing the circular dependencies.

Personally, I'd suggest not having the separate -config package; and
letting sites do their own exim configurations manually, rather than by
creating a replacement -config package. Then you should be able to set
things up so that:

exim4-daemon
- has a postinst which starts the daemon
- Provides/Conflicts: m-t-a
- Depends: exim4-base
exim4-base
- has no postinst
- needs no configuration
- provides common support files
- Depends: exim4-daemon

Having a check to say "/etc/exim/exim.conf already exists? well, obviously
you don't need any help" and not asking any debconf questions is one
way that should work, specifically asking "do you want to configure exim
manually?" is another.

If that's really out of the question, and the -config or -base package needs
a postinst atm, a Pre-Depends is probably the best option.

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


pgp4QJffJQsl2.pgp
Description: PGP signature

Re: OT: Smartcards and Physical Security

[Tom]

On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote:
>   Heh. Your grasp of the practicality of the situation is
>  slipping.  Not only do these guys donate a fairly expensive chunk of
>  billable hours and expertise, they must pay to be able to volunteer?

Sure, if you care about security.

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

[Manoj Srivastava]

On Tue, 2 Dec 2003 23:46:45 +, Geoff Richards <[EMAIL PROTECTED]> said: 

> On Tue, Dec 02, 2003 at 01:28:28PM -0800, Tom wrote:
>> I read all the words but took a completely different meaning :-)
>> I'm from the South, we have different speech patterns...

> South of where?

The Mason-Dixon line?

manoj
-- 
Beware of all enterprises that require new clothes, and not rather a
new wearer of clothes. Henry David Thoreau
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Andreas Tille]

On Wed, 3 Dec 2003, cobaco wrote:

> hm, I've added a definition to the wiki:
>
>   A Custom Debian Distribution (CDD) is a version of Debian that is tailored
I do not like the term "version".  I'd prefer a "subset of Debian".  You
get a CDD together with main but you get a helping hand to cope with the
sheer mass.
>   for a particular situation/target group out-of-the-box.
>
>   Any changes necessary to Debian to support this particular situation/target
>   group arge merged back into Debian whenever possible, improving Debian as a
>   whole.
There are no changes to Debian, because CDDs reside completely in
main / testing /unstable as any other package.

Kind regards

Andreas.

Re: [RFC] adding system users: which is the best way??

[Anthony DeRobertis]

On Sun, 2003-11-30 at 07:47, Bernhard R. Link wrote:

> Could anyone familar with cups explain why this is no RC-bug? 

From when I've seen it do it, for the same reason SWAT and webmin aren't
RC bugs: They do it because the administrator said to change the config.


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

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
> 
> > But this kind of tampering _can_ be checked by apt before installing
> > the deb simply by adding a signature verifyer into the
> > DPkg::Pre-Install-Pkgs config option, the same mechanism
> > apt-listchanges already uses to display only the new section of the
> > changelog.
> 
> Indeed, apt can do a lot better, and is very close to doing so. See #203741.

The assumption was that the archive was compromised but the
Release.gpg file changed and resigned. #203741 is about checking the
Release.gpg chain of trust or is there more hidden in all the mails.

Did the BTS reoder the mails, there don't seem to follow a locigal
discussion. Haven't bothered to check the timestamps though.

MfG
Goswin

Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?

[Gabor Burjan]

On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote:

> wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file
> wget -q -O 2.deb http://security.debian.org/pool/updates/$file
> diff 1.deb 2.deb
> 
> Binary files 1.deb and 2.deb differ
> 
> How could this happen? Should I worry about it?

$ diff -u <(cd 1 && find . -type f -print0 | xargs -0 md5sum) <(cd 2 && find . 
-type f -print0 | xargs -0 md5sum)
--- /dev/fd/63  Wed Dec  3 18:11:59 2003
+++ /dev/fd/62  Wed Dec  3 18:11:59 2003
@@ -4,5 +4,5 @@
 efcb0a3d92c575963f4cd4e4f79f425f  ./usr/share/doc/libpng2/changelog.gz
 54119d0a36cff7d0822489193119fc83  ./usr/share/doc/libpng2/ANNOUNCE.gz
 ebe766baed86109342285496d792d3ef  ./usr/share/doc/libpng2/KNOWNBUG.gz
-9371022fb0313ab0b2062202383c57ec  ./usr/share/doc/libpng2/changelog.Debian.gz
+3f9dfa57c390b6465b655e12f4b3490a  ./usr/share/doc/libpng2/changelog.Debian.gz
 27164cfa4772e8424149aaa801119ead  ./usr/lib/libpng.so.2.1.0.12
$ diff -u <(zcat 1/usr/share/doc/libpng2/changelog.Debian.gz) <(zcat 
2/usr/share/doc/libpng2/changelog.Debian.gz)
$

It looks like that the two binary packages were built on different places but
have basically the same content.

Gabor

Re: INSTALL-REPORT

[Joshua Kwan]

On Wed, Dec 03, 2003 at 09:22:14AM +0100, Werner Wobrowsky wrote:
> Debian Installer sarge-i386-bussinescard.iso, httP://freedesktop.or/

Cool, but...

> FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEW

I didn't know the sarge ISOs supported Debian/FreeBSD. :)
Wrong dmesg?

-- 
Joshua Kwan


pgpIROADjx2N3.pgp
Description: PGP signature

Bug#222807: ITP: distcmd -- Distribute load to multiple machines using ssh

[Anthony DeRobertis]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: distcmd
  Version : 0.9
  Upstream Author : Anthony DeRobertis <[EMAIL PROTECTED]>
* URL : http://ntp.derobert.net/DistCmd/
* License : GPL
  Description : Distribute load to multiple machines using ssh

 DistributedCommand allows you to run commands load-balanced over
 one or more machines. Notable features include performing all remote
 control of machines using ssh; transfering files over scp or a shared
 filesystem, on a per-host basis; and avoiding copying through hardlinks
 when possible.
 .
 Out of the box, it supports running oggenc to encode Ogg Vorbis
 streams. An example of how to use it with Jack the Ripper is included.


NOTE: Packages are available at the above URL. That URL is not going to
  last forever, though

  I need a sponsor for this.

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

iD8DBQE/zfVF+z+IwlXqWf4RAmR7AJ4jMHVOyJk3a5MWxTgEUXvU4r3SjQCeMqbs
71w0U2whdvZ82IBeSs+YKhE=
=2HqB
-END PGP SIGNATURE-

Re: [RFC] adding system users: which is the best way??

[Anthony DeRobertis]

On Sun, 2003-11-30 at 12:29, Steve Greenland wrote:
> I think the idea of a namespace for usernames used by packages is a good
> idea, but rather than "debian-", we should take this to the LSB folk, so
> that we can get it done once.

As long as the LSB allocates an area for distribution-created names, to
be used at the distribution's discretion, that's a very good idea.

If they want to create separate namespaces for LSB names and maybe
third-party vendor names, too, that's fine.


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

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Wed, 3 Dec 2003 01:24:50 -0800, Tom  <[EMAIL PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom Ballard wrote:

> Oh, one last thing: each DD should pay for the device him/her self
> and should be required to fly to meet wherever they can pick them
> up.  Why do you assume somebody has to pay for everything?  What's
> wrong with bearing some of the costs yourself?  This is a big deal.


Heh. Your grasp of the practicality of the situation is
 slipping.  Not only do these guys donate a fairly expensive chunk of
 billable hours and expertise, they must pay to be able to volunteer?

manoj
-- 
No one gets sick on Wednesdays.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C