Re: debconf 2005 in Vienna, Austria

[Martin List-Petersen]

On Sat, 2003-08-02 at 21:31, Thomas Viehmann wrote:
> Sven Luther wrote:
> > You are aware that due to the high heat we had in france this early
> > summer, lot of train going to the south of france did blew a fuse or
> > something because of the climatisation or something such, and thus where
> > delayed various hours (until the time became cooler, the climatisation
> > used less current and thus the whole train could go forward or something
> > such). So maybe the use of a lot of power for notebooks, some using
> > quite hot processors, could in addition to the climatisation problem be
> > a problem.
> 
> If you end up in southern France on your way from Karlsruhe to Vienna then the
> problem is not the air conditioning of the train.

At least we're sure then, that the GPS software needs some major
calibration :)

Regards, 
Martin List-Petersen 
martin at list-petersen dot dk 
-- 
It is better to wear out than to rust out.


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

Re: libraries being removed from the archive

[LapTop006]

On Sat, Aug 02, 2003 at 09:32:37PM -0500, Chris Cheney arranged a set of bits 
into the following:
> Today I was reminded of something that causes apps not to migrate into
> sarge.  When maintainers remove old libraries from the archive!  Today
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9.  Guess what that does... any package which depends on libexif8
> now becomes... you guessed it... UNINSTALLABLE!  Why does this annoy me
> in particular, because I just uploaded kdegraphics yesterday which was
> built against libexif8. Guess how many hours it takes for the m68k
> buildd to rebuild kdegraphics. OVER 38 HOURS!
> 
> IMHO we need to make an addition to policy stating that an old lib can
> not be removed from the archive until no other packages still depend on
> it.
How about old libraries can not be removed until either no packages
depend on it OR the author files RC bugs with any dependent pakcages
(and hopefully waits for at least a day in case of any major problems)?

This way ancient libraries can go, and the maintainers of packages
depending on these libraries don't have to constantly keep an eye on
bugs for ftp.d.o. The only downside would be filing all the bugs, and
this might be a good way to dissuade people from removing libraries that
are widely used.


pgpSiCkA9ofoH.pgp
Description: PGP signature

Re: debconf 2005 in Vienna, Austria

[Matthias Urlichs]

Hi, Joel Baker wrote:

> Diesel locomotives are a giant diesel generator hooked up to electric
> traction motors, running through the switchbox at something like 600v
> (I haven't read the specs in a while, this might be off - but it's high
> enough to warrant being really careful around). Don't even ask about the
> amperage. Sapping off a little power to run a few household outlets is, by
> comparison, peanuts. Or, really, peanut crumbs.

... assuming that the circuitry used to sap off 220Vac from that is up to
the task.

A few years ago in Germany there was a huge stink raised by the
environmentalists (rightly so, IMHO) because the mid-range trains running
on nonelectrified trains sometimes ran with two Diesel locomotives so that
the coffee machines in the train bistro could get enough juice.  :-/

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
"Finding that no religion is based on facts and cannot be
 true, I began to reflect what must be the condition of
 mankind trained from infancy to believe in error."
 [Robert Owen, 19th century reformer]

Re: CUPS should be the default print service in Debian/Sarge

[Marc Wilson]

On Sat, Aug 02, 2003 at 02:51:53AM -0500, Joe Wreschnig wrote:
> For the vast majority of situations, it's incredibly easier to configure,
> and usually more reliable about output, than lprng.

Implying that there are circumstances where CUPS will produce valid output,
and lprng will not?  I'm interested.  Examples, please.

-- 
 Marc Wilson | Old programmers never die, they just hit account
 [EMAIL PROTECTED] | block limit.


pgphd3U8NKqMo.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote:

>   Given the last review of a setgid program, I wonder if two
>  people are enough.

Surely two people would be an improvement over the current situation, where
there is no review at all.  Our demonstration has shown how one person can
discover some common flaws with a relatively brief review.

This bug and others existed in your package for over four years (and still
exist in stable today).  We might still not know about it if you had not
brought the package to my attention for review.  Steve Kemp might have
eventually discovered it in the course of his auditing, but I don't know
whether he is spending his time on non-free software such as angband.

Keep in mind that there are also potentially more than two people interested
in this review process.  Another person besides myself has already
volunteered in just the first day of discussion, and I find this very
encouraging.

>  The mistake was simple, human, and undesrtandable, but the review does
>  not in fact talk about any flaws in the current version of angband

The review, simplistic though it was, uncovered flaws in the package in
stable which were overlooked by the maintainer.  This kind of situation is
often preventable through discussion and code review, as you have seen.  I
would like to promote this beneficial process within Debian in order to
reduce the workload of the security team and the presence of vulnerabilities
in our stable releases.

-- 
 - mdz

Re: libraries being removed from the archive

[Eduard Bloch]

#include 
* LapTop006 [Sun, Aug 03 2003, 03:13:57PM]:

> > IMHO we need to make an addition to policy stating that an old lib can
> > not be removed from the archive until no other packages still depend on
> > it.
> How about old libraries can not be removed until either no packages
> depend on it OR the author files RC bugs with any dependent pakcages
> (and hopefully waits for at least a day in case of any major problems)?

Old libraries are removed since only one version can exist in the same
distro branch to the same time. If the library maintainer decided not to
fork the source package but change the binary package name inside of
existing three then he does not care about the users of his package.
Such actions (in-place transition) should always be done in coordination
with fellow developers as happened in the Perl transition, for example.

MfG,
Eduard.
-- 
Genossen können nicht die Faust ballen, weil sie überall die Finger
drin haben.


pgpkyvlyMg8FK.pgp
Description: PGP signature

Re: mutt co-maintainer badly needed

[Aaron Lehmann]

On Sun, Aug 03, 2003 at 04:37:53AM +0200, Marco d'Itri wrote:
> - eventually packaging the mutt CVS tree, as the author has not made any
>   new snapshots in the last months

He doesn't seem to be committing much, either. A patch I sent was
repeatedly ignored.

Re: debconf 2005 in Vienna, Austria

[Andreas Barth]

* Matthias Urlichs ([EMAIL PROTECTED]) [030803 08:35]:
> A few years ago in Germany there was a huge stink raised by the
> environmentalists (rightly so, IMHO) because the mid-range trains running
> on nonelectrified trains sometimes ran with two Diesel locomotives so that
> the coffee machines in the train bistro could get enough juice.  :-/

This is still valid, e.g. on Munich - Zürich, as the German goverment
declines to electrify this line (and also declines to let the Swiss do
it). But we're now heavily off-topic.


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

Re: debconf 2005 in Vienna, Austria

[Andreas Metzler]

Christian Perrier <[EMAIL PROTECTED]> wrote:
> Quoting Riku Voipio ([EMAIL PROTECTED]):
>> Trains (atleast the newer ones in finland) have electric sockets,

> 

> This is still quite rare. For instance, in french trains (TGV and
> "Teoz", formerly known as "Corail"ie Intercity trains), electric
> wires are only available in the most recent coaches and only in 1st
> class usually.
[...]

The Austrian railway company (www.oebb.at) has started providing wall
sockets in 2nd class in EC trains about 6 months ago. The one I
frequent regularily (4-5 times a year) _really_ has them.
cu andreas

Re: setuid/setgid binaries contained in the Debian repository.

[Steve Kemp]

On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote:
> 
>   Given the last review of a setgid program, I wonder if two
>  people are enough. The mistake was simple, human, and undesrtandable,
>  but the review does not in fact talk about any flaws in the current
>  version of angband (tome does need to be so changed); and this kind
>  of error would undermine the process -- especially if the results are
>  couched in terms like those below:

  I think it's accepted that no matter how many people look at a piece
 of code that there may be things missed.

  There are programs I've examined in the past which I believed were OK
 only to later see that they contained flaws.  It's easy to imagine
 things would still be overlooked with more people looking at the code,
 so a "false positive" review would occur.
 
  However what's the worst that could happen?  If there were a team and
 they messed up we'd have a vulnerable program in the archive which is
 exactly what we have now.  If something were spotted then it could be
 fixed and we'd have reached a better degree of security than that which
 we currently enjoy.

  Given the time it would take for a few people to look over a program
 I think it's a reasonable suggestion, and worth doing even if it doesnt
 catch *everything*.

Steve
---


pgp5MhTeqFMFt.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Steve Kemp]

On Sun, Aug 03, 2003 at 03:14:23AM -0400, Matt Zimmerman wrote:

> Surely two people would be an improvement over the current situation, where
> there is no review at all.  Our demonstration has shown how one person can
> discover some common flaws with a relatively brief review.

  *Exactly*.  Well said.
> Keep in mind that there are also potentially more than two people interested
> in this review process.  Another person besides myself has already
> volunteered in just the first day of discussion, and I find this very
> encouraging.

  I find that very pleasing also.  I have no desire to go down a *BSD
 route and audit every single thing, (mostly due to a lack of time),
 but it's good to see that there are people interested in this kind of
 work.

> I would like to promote this beneficial process within Debian in order to
> reduce the workload of the security team and the presence of vulnerabilities
> in our stable releases.

  I did feel a little guilty when reporting so many issues that I was
 putting unfair pressure upon the security team to release fixes, but I
 assumed if that were the case somebody would tell me.
  
  Anything that could make it easier for the security team to do their
 job is a good thing as you do such a good and important job.  Thanks to
 all of you.

Steve
---


pgpDAvsb7jebr.pgp
Description: PGP signature

Re: setgid crontab

[Steve Greenland]

On 02-Aug-03, 23:36 (CDT), Matt Zimmerman <[EMAIL PROTECTED]> wrote: 
> So: open, fstat, stat, compare fstat.st_ino to stat.st_ino, check
> fstat.st_uid.  O_EXCL should also be used when writing to the directory.

That introduces a (possibly minor) race condition: if the user runs
crontab to replace their file between the open() and stat() calls,
this check will fail. Not a huge problem, because it will pick it up
correctly the next time cron runs. And better to have the check than
not, I agree.

For the record, the way crontab add/replaces the user's file is to
first create a tmp file in the spool directory, check that it parses
correctly, and then rename() it to the user's name.

I'll take a look at the OpenBSD and Solar Designer implementations, and
see what they did.

> It should be noted somewhere that these protections do little good if the
> system allows users to give away their files (as with the recent XFS bug),
> and gid cron becomes equivalent to root again.

Nor do they do any good if root's password is empty. Not cron's problem.
(Insert standard homily about security and the chain's weakest link.)

Steve

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

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 
> 
>   Packaging informatoin, not program behaviour affected by
>  this. Packaging details are determined by developers, and can be
>  easily changed. 

In certian cultures, including mine, gratutious repitions of ones point
is considered childish and rude and something most of us outgrow by age
6.

Anyway, you seem to be arguing that policy cannot make mandates that
require significant changes to the source or behavior of programs, which
is not true at all. Policy requires that packages bt FHS compliant; this
often means large changes to the endire organisation of packages,
including large source code changes and design changes. (See the
space-orbit package for a good example.) Policy asks that window
managers support the debian menu system, this has required significant
changes in the code of less-capable window managers such as twm. Policy
requires that everything in debian use the same backspace/delete
keyboard mapping, which requires changes all over the place. Policy
requires that programs not depend on environment variables to function,
which can easily mean that a program's source code must be changed to
make it read a config file instead. These are just a few examples.

-- 
see shy jo


pgp6RKrEq44xi.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Matt Zimmerman wrote:
> There are other solutions, including group membership, but it doesn't
> matter, because that is not what I am talking about.  The fact is, many
> programs run with privileges that they do NOT require in order to function
> acceptably, or even fully, and I want to promote discussion in order to
> prevent that situation.

Just for example, I sat down and audited mooix's user of setuid and
setgid bits the other day. When I started, mooix contained 3 interactive
setuid root programs, 2 setuid helper programs with well-defined and
very small user inputs, and one daemon that ran as root. When I
finished, mooix contained 3 programs setuid and/or setgid to users and
groups with limited permissions, 3 setuid helper programs, and one
daemon that drops permissions to nobody after it's done with PAM. Overall
300 fewer lines of code run as root. And better gains that this are
possible in many other packages in debian.

-- 
see shy jo


pgpPvaGTOXtiE.pgp
Description: PGP signature

Re: setgid crontab

[Joey Hess]

Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
> calls), this involves the following changes:
> 
> add system group 'cron'
> 
> change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> 
> change crontab files in the spool directory from 600 root.root to 600
> userid.cron
> 
> At first glance, the only access I've added with this is that a user can
> now view or edit (but not delete) her crontab file directly in the spool
> directory. Since one could all that with the crontab command anyway, it
> doesn't seem a big deal.
> 
> Comments, suggestions?

One possible gotcha is that if crontab(1) does any sanity checks of the
crontab files, cron could expect them to be pre-sanitised, and might
behave badly if an unsanitised file is put into place by a user.

(As a user, what I really want is a .crontab file in my home directory,
so I can put it under revision control.)

-- 
see shy jo


pgpYBd5QDWDKw.pgp
Description: PGP signature

Re: debconf 2005 in Vienna, Austria

[Joel Baker]

On Sun, Aug 03, 2003 at 08:05:01AM +0200, Matthias Urlichs wrote:
> Hi, Joel Baker wrote:
> 
> > Diesel locomotives are a giant diesel generator hooked up to electric
> > traction motors, running through the switchbox at something like 600v
> > (I haven't read the specs in a while, this might be off - but it's high
> > enough to warrant being really careful around). Don't even ask about the
> > amperage. Sapping off a little power to run a few household outlets is, by
> > comparison, peanuts. Or, really, peanut crumbs.
> 
> ... assuming that the circuitry used to sap off 220Vac from that is up to
> the task.
> 
> A few years ago in Germany there was a huge stink raised by the
> environmentalists (rightly so, IMHO) because the mid-range trains running
> on nonelectrified trains sometimes ran with two Diesel locomotives so that
> the coffee machines in the train bistro could get enough juice.  :-/

Mmm. True enough; older locomotives were generally expected to run basic
environmental (heat, A/C, lighting) and if it hasn't been refitted, that
might be an issue. Which is silly, really, but nobody really envisioned
personal use of appliances throughout, at least when the earlier units were
being built (and yes, stuff from the 50s is still in active service today).

I suppose one could always ask the rail company if they could arrange a
locomotive with a new enough setup that it was intended to be used with
such, but I'd have no idea how to do that for a European railway (now, if
you want to ask BNSF or Union Pacific, I might be able to find out... :)
-- 
Joel Baker <[EMAIL PROTECTED]>


pgpAJmdlZNdVK.pgp
Description: PGP signature

Re: proposal: per-user temporary directories on by default?

[Tollef Fog Heen]

* Kevin Kreamer 

| Tollef Fog Heen <[EMAIL PROTECTED]> writes:
| > ATM, TMPDIR is defined using #define in libpam-tmpdir's source.
| > Patches for having that as a run-time configuration are accepted.
| 
| I recently posted to debian-devel a patch to do this (not sure
| whether you saw it or not).

I saw it, thanks

[...]

| [1] My solution as to how to get the path from libpam-tmpdir to
| pam-tmpdir-helper was to pass it on the command line.  But, since
| anyone can run pam-tmpdir-helper, anyone can create any tmpdir they
| like anywhere on the system.  Very bad.

Adding a sanity check that the base directory is owned by root, would
that suffice?

I think I'll have to think about this a little.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 03:14:23 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote:

> This bug and others existed in your package for over four years (and
> still exist in stable today).  We might still not know about it if
> you had not brought the package to my attention for review.  Steve
> Kemp might have eventually discovered it in the course of his
> auditing, but I don't know whether he is spending his time on
> non-free software such as angband.

You note that the bugs have been fixed over a year ago. 

> The review, simplistic though it was, uncovered flaws in the package
> in stable which were overlooked by the maintainer.  This kind of
> situation is often preventable through discussion and code review,
> as you have seen.  I would like to promote this beneficial process
> within Debian in order to reduce the workload of the security team
> and the presence of vulnerabilities in our stable releases.

I haven't objected to code reviews of packages; I objected to
 gathering consensus through discussion; and making admission of new
 packages incumbent on such consensus. 

Now, if this proposal is all about getting the  code reviewd,
 and it is merely a recommendation, as you have implied recently, then
 change the stated wording to reflect that.

manoj

-- 
"You can measure a programmer's perspective by noting his attitude on
the continuing viability of Fortran." Alan Perlis
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: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sat, 2 Aug 2003 22:17:16 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Sat, Aug 02, 2003 at 08:14:15PM -0500, Manoj Srivastava wrote:
>> Heh. You should look at what is in the current version:

> Is that what you would say to the users who have angband installed
> on Woody?  I do not think this is something to laugh about.

There are any number of old programs where security was not an
 issue -- and yes, angband is one where such a makeover was only
 performed in the last year. 

I must confess that my security audits did not include
 angband; I was more concerned with my packages in Debian, and I
 should have paid more attention to angband earlier.

manoj
-- 
It is a wise father that knows his own child. William Shakespeare,
"The Merchant of Venice"
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: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 11:59:03 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> In certian cultures, including mine, gratutious repitions of ones
> point is considered childish and rude and something most of us
> outgrow by age 6.

I would much rather you restricted your responses to the
 substance of the discussion, rather than attacking the style and
 culture of the respondent; this project is supposed to have a
 multicultural membership: all the world is not american, and I think
 people may need to learn to live with that. 

> Anyway, you seem to be arguing that policy cannot make mandates that
> require significant changes to the source or behavior of programs,
> which is not true at all.

Not without a transition plan in the general case. And my
 point, which you have not addressed, was that most of your examples
 were not ones that mandated significant changes to the source or
 behavior of programs.

> Policy requires that packages bt FHS compliant; this often means
> large changes to the endire organisation of packages, including
> large source code changes and design changes. (See the space-orbit
> package for a good example.)

Surely you recall the time that was afforded developers to
 accomplish the /usr/doc -> /usr/share/doc change? We did not mandate
 FHS compliance with a simple change to policy mandates. 

> Policy asks that window managers support the debian menu system,
> this has required significant changes in the code of less-capable
> window managers such as twm. Policy requires that everything in
> debian use the same backspace/delete keyboard mapping, which
> requires changes all over the place. Policy requires that programs
> not depend on environment variables to function, which can easily
> mean that a program's source code must be changed to make it read a
> config file instead. These are just a few examples.

First, most of these alloowed people time to bring their
 programs in line. Secondly,, no new programs were kept out of the
 distribution by requiring an audit and a consensus on debian-devel;
 You got the program in, and you worked on the bugs that were filed on
 it.


Using a policy directive as a gating mechanism has never, ever
 been done.

manoj
-- 
Diplomacy is to do and say, the nastiest thing in the nicest
way. Balfour
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: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 00:16:59 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Sun, Aug 03, 2003 at 10:57:51AM +0900, Oohara Yuuma wrote:
>> I don't care if you mandate a prior peer view _request_ (not prior
>> approval)

> This is what was proposed, except that it was recommended rather
> than mandated.

The proposal makes it a bug if you do not manage to achieve
 consensus (not a rough consensus -- a flat out consensus) on
 debian-devel. 

manoj
-- 
Loose bits sink chips.
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: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   Not without a transition plan in the general case. And my
>  point, which you have not addressed, was that most of your examples
>  were not ones that mandated significant changes to the source or
>  behavior of programs.

>   First, most of these alloowed people time to bring their
>  programs in line. Secondly,, no new programs were kept out of the
>  distribution by requiring an audit and a consensus on debian-devel;
>  You got the program in, and you worked on the bugs that were filed on
>  it.

So by analogy, the debian-legal list should not be able to block new
software with potentially bad licenses from entering the archive.
Instead we should have some kind of "teansition plan". Fascinating, tell
me more.

-- 
see shy jo


pgpZk3K3CKWlV.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   I haven't objected to code reviews of packages; I objected to
>  gathering consensus through discussion; and making admission of new
>  packages incumbent on such consensus. 

Again, how is this different from the debian-legal mailing list?

-- 
see shy jo, amazed at the phrase "I objected to gathering consensus
  through discussion"


pgpI0EX8ee04j.pgp
Description: PGP signature

Re: libraries being removed from the archive

[Chris Cheney]

On Sun, Aug 03, 2003 at 08:55:48AM +0200, Eduard Bloch wrote:
> #include 
> * LapTop006 [Sun, Aug 03 2003, 03:13:57PM]:
> 
> > > IMHO we need to make an addition to policy stating that an old lib can
> > > not be removed from the archive until no other packages still depend on
> > > it.
> > How about old libraries can not be removed until either no packages
> > depend on it OR the author files RC bugs with any dependent pakcages
> > (and hopefully waits for at least a day in case of any major problems)?
> 
> Old libraries are removed since only one version can exist in the same
> distro branch to the same time. If the library maintainer decided not to
> fork the source package but change the binary package name inside of
> existing three then he does not care about the users of his package.
> Such actions (in-place transition) should always be done in coordination
> with fellow developers as happened in the Perl transition, for example.

Hence the need for policy to dictate to the maintainer not to allow the
package to be removed before all other packages have transitioned. It
usually doesn't take much more work as long as the maintainer is even
aware of what will happen.

Chris

Re: libraries being removed from the archive

[David Z Maze]

Chris Cheney <[EMAIL PROTECTED]> writes:

> IMHO we need to make an addition to policy stating that an old lib can
> not be removed from the archive until no other packages still depend on
> it.

So say I maintain foo.  The source package produces two binary
packages, foo and libfoo1.  Now, there's a new foo release, that
changes libfoo's soname.  In the current scheme, I package the new
upstream release and upload foo and libfoo2; since there's no source
package for libfoo1, it eventually gets removed from unstable.

Are you proposing that (a) the ftpmasters not remove libfoo1, or (b)
that package maintainers of library packages are now compelled to
package the last version of foo's source providing libfoo1 separately,
potentially for multiple release cycles for a widely used library?
Option (b) sounds problematic to me...

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
-- Abra Mitchell

Re: setgid crontab

[Manoj Srivastava]

On Sun, 3 Aug 2003 12:37:46 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> (As a user, what I really want is a .crontab file in my home
> directory, so I can put it under revision control.)

Umm, as a work around, I have ~/etc/crontab, and at one time
 had a cron job that tested the output of crontab -l periodically, and
 updated as needed. (I update my cron file seldom enough that I now
 just do it manually). 

manoj
-- 
Recent research has tended to show that the Abominable No-Man is being
replaced by the Prohibitive Procrastinator. C.N. Parkinson
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: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 13:24:13 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> Not without a transition plan in the general case. And my point,
>> which you have not addressed, was that most of your examples were
>> not ones that mandated significant changes to the source or
>> behavior of programs.

>> First, most of these alloowed people time to bring their programs
>> in line. Secondly,, no new programs were kept out of the
>> distribution by requiring an audit and a consensus on debian-devel;
>> You got the program in, and you worked on the bugs that were filed
>> on it.

> So by analogy, the debian-legal list should not be able to block new
> software with potentially bad licenses from entering the archive.
> Instead we should have some kind of "teansition plan". Fascinating,
> tell me more.

*Sigh*. I didn't think I would need to tell you about our
 social contract, nor that you would find that exposition
 fascinating. Since even you appear to be confused about this
 distinction, perhaps I should not be making assumptions about other
 readers of this list. 

Hmm. See, we have this thing called the social contract,
 which we all agreed to, and which is one of the core things about
 Debian. The social contract provides a guideline to determine what we
 call free.

That is hard at times to do, so we have a bunch of people,
 who, in the goodness of their heart, donate time to help people
 determine how to apply those guidelines.

I also note that the -legal list does have gating rights over
 every package; they mostly respond to request from maintainers who
 are confused about some license. Packages are not held up until the
 list provides the proper penguin pee. There is no dictum in policy to
 beat people on the head with to make them go to the list and get
 consensus.

It is one thing to have a clearinghouse where expertise
 lives, and to have that clearinghouse offer expert services when a
 developer is in doubt, and quite another to use policy to ram these
 volunteer services down every ones throats.

Did you find this as elucidating as my previous message?

> Manoj Srivastava wrote:
>> I haven't objected to code reviews of packages; I objected to
>> gathering consensus through discussion; and making admission of new
>> packages incumbent on such consensus.

> Again, how is this different from the debian-legal mailing list?

Again, there is nothing in policy that requires a consensus on
 the -legal mailing list in order for packages to be included in the
 project.

If I am confused about a license, yes, the -legal list exists
 to disambiguate the license; and help me decide whether it should or
 should not be in Debian. No beating me on the head with policy at
 all. 

Is this distinction really so hard to see?

I would be enthusiastically for a list like -legal, where
 people can go and ask for help to have packages audited, but not for
 people rolling up policy to beat people on the head to make it so.

manoj
-- 
"Keeping proprietary and confidential information secret is the key to
moving the computer industry into the 21st century." Letter from Apple
Computer and Rasterops to the Macintosh user community
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: setgid crontab

[Tollef Fog Heen]

* Joey Hess 

| (As a user, what I really want is a .crontab file in my home directory,
| so I can put it under revision control.)

have a .crontab in your ~ with a line similar to

@daily crontab $HOME/.crontab

?

(Naturally, you'd have to get that crontab initially installed,
though.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: proposal: per-user temporary directories on by default?

[Kevin Kreamer]

Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> * Kevin Kreamer 
> [...]
>
> | [1] My solution as to how to get the path from libpam-tmpdir to
> | pam-tmpdir-helper was to pass it on the command line.  But, since
> | anyone can run pam-tmpdir-helper, anyone can create any tmpdir they
> | like anywhere on the system.  Very bad.
>
> Adding a sanity check that the base directory is owned by root, would
> that suffice?
>
> I think I'll have to think about this a little.

Ok, I've done some thinking on this as well, and this is what I've
come up with.  I don't think making sure that the base directory is
owned by root will protect you, as that would still allow an
attacker to put a tmpdir in most system areas.  What we really need
is to make sure that the tmpdir is created where the admin wants, not
where the user wants.

Since the helper has to be setuid, and has to runnable by anyone
(since the PAM stuff uses the permissions of whoever is logging in),
we can't pass the path into the helper.  It has to already know where
to make the path.  So, it seems to me that the best approach is to
have both pam_tmpdir.so and the helper read the configuration file
independently to find out where to put the tmpdir.  However, since
the helper won't know what service is being used, and therefore won't
know which pam.d file to read, we'll have to use a completely
independent config file (/etc/pam-tmpdir.conf or something like that).

What do you think?

Kevin



pgpWqpo21fdOd.pgp
Description: PGP signature

Re: libraries being removed from the archive

[Chris Cheney]

On Sun, Aug 03, 2003 at 03:55:41PM -0400, David Z Maze wrote:
> Chris Cheney <[EMAIL PROTECTED]> writes:
> 
> > IMHO we need to make an addition to policy stating that an old lib can
> > not be removed from the archive until no other packages still depend on
> > it.
> 
> So say I maintain foo.  The source package produces two binary
> packages, foo and libfoo1.  Now, there's a new foo release, that
> changes libfoo's soname.  In the current scheme, I package the new
> upstream release and upload foo and libfoo2; since there's no source
> package for libfoo1, it eventually gets removed from unstable.
> 
> Are you proposing that (a) the ftpmasters not remove libfoo1, or (b)
> that package maintainers of library packages are now compelled to
> package the last version of foo's source providing libfoo1 separately,
> potentially for multiple release cycles for a widely used library?
> Option (b) sounds problematic to me...

libfoo1 gets automatically removed immediately upon installation of
libfoo2 in the archive currently.  The proper way to fix this issue
is when the maintainer uploads new libfoo source with libfoo2 package
in it to also upload a source called libfoo1 that only provides the
libfoo1 binary package [0]. I have done this myself for libao0 in the
past. Once libfoo1 is no longer used by anything you can simply remove
it from the archive without having to modify anything. I seriously
doubt at the speed of Debian's "release cycle" you would need to have
the old library in the archive for more than one release, probably not
even that long. You do realize that Debian's "release cycle" is
currently 2 years per release...?

Chris Cheney

[0] Both the libfoo and libfoo1 source will be marked NEW so assuming
that both get processed at the same time packages depending on libfoo1
won't become uninstallable.

Re: libraries being removed from the archive

[christophe barbe]

You are kidding right?

I have not removed an old library, I have uploaded a newer upstream with
a different soname. That's the way it works, a new library is uploaded,
then packages using it are rebuilt and when they are all ready they
migrate in testing. 

As the gphoto2 maintainer, I don't remember getting mails from you
announcing an upcoming libusb package with a new soname. Perhaps that's
because I was waiting for a few months to get a working one for our
powerpc users.

IMHO we need to make an addition to the policy stating that not being an
asshole on the mailing-list is welcome. I don't remember sending mails
to the mailing list when the libusb packaging was broken for a few
months, but I do remember sending you polite mails.

For you information, some packages using libexif need libexif9.
I agree that I could (should) have sent a prior notice before uploading it 
(more than a week ago, BEFORE your kdegraphics upload), but that's not
an excuse to be an asshole.

Christophe

On Sat, Aug 02, 2003 at 09:32:37PM -0500, Chris Cheney wrote:
> Today I was reminded of something that causes apps not to migrate into
> sarge.  When maintainers remove old libraries from the archive!  Today
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9.  Guess what that does... any package which depends on libexif8
> now becomes... you guessed it... UNINSTALLABLE!  Why does this annoy me
> in particular, because I just uploaded kdegraphics yesterday which was
> built against libexif8. Guess how many hours it takes for the m68k
> buildd to rebuild kdegraphics. OVER 38 HOURS!
> 
> IMHO we need to make an addition to policy stating that an old lib can
> not be removed from the archive until no other packages still depend on
> it.
> 
> Chris Cheney
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

A qui sait comprendre, peu de mots suffisent.
(Intelligenti pauca.) 

Re: libraries being removed from the archive

[Chris Cheney]

On Sun, Aug 03, 2003 at 05:31:37PM -0400, christophe barbe wrote:
> You are kidding right?
> 
> I have not removed an old library, I have uploaded a newer upstream with
> a different soname. That's the way it works, a new library is uploaded,
> then packages using it are rebuilt and when they are all ready they
> migrate in testing. 
> 
> As the gphoto2 maintainer, I don't remember getting mails from you
> announcing an upcoming libusb package with a new soname. Perhaps that's
> because I was waiting for a few months to get a working one for our
> powerpc users.
> 
> IMHO we need to make an addition to the policy stating that not being an
> asshole on the mailing-list is welcome. I don't remember sending mails
> to the mailing list when the libusb packaging was broken for a few
> months, but I do remember sending you polite mails.
> 
> For you information, some packages using libexif need libexif9.
> I agree that I could (should) have sent a prior notice before uploading it 
> (more than a week ago, BEFORE your kdegraphics upload), but that's not
> an excuse to be an asshole.
> 
> Christophe

You aren't the only one that has broken things, many other people
including myself have as well, I most notably with libvorbis ;). However,
this libusb soname change you mention last happened on Feb 27 2002,
which was changed due to a RC bug regarding its naming. (BTW libusb's
soname is odd, which is why I didn't catch it sooner). Also you mention
that libusb was broken for several months, which is true, but it was
only broken on one arch (powerpc).  Also, from what I can tell from
looking back at it by the time you determined it wasn't a bug in
gphoto2 you NMU'd it within a week. I don't recall if I was actually
aware of the bug before you NMU'd it.

Also, I was not stating that libexif9 should not be uploaded, only that
old libraries should not be removed from the archive until they are no
longer used, which apparently was not the case for libexif8. I don't
recall if I stated this earlier but each time I have uploaded KDE in the
past several months it has been broken by library removals within about
a week and recompiling KDE sources is not light work for the buildds.

Seriously, if we want to ever release sarge we are going to need to stop
making libraries disappear, every time we rebuild something it takes
another 10 days for it to migrate into testing and everything that
depends on it is also pushed back another 10 days. Even if the person
causing the breakage NMU's all the affected packages it still causes
them to wait another 10 days to migrate, and causes unneeded load on
the buildds, possibly with the packages no longer being able to be
built since gcc 3.3 is so anal now. (/me wonders how many RC bugs are
around just for gcc 3.3 related crap)

BTW - For those wondering Woody was released over a year ago...

Thanks,

Chris Cheney

PS - I apologize for sounding like an asshole, however this general
problem really does need fixing.

Re: CUPS should be the default print service in Debian/Sarge

[Joe Wreschnig]

On Sun, 2003-08-03 at 01:44, Marc Wilson wrote:
> On Sat, Aug 02, 2003 at 02:51:53AM -0500, Joe Wreschnig wrote:
> > For the vast majority of situations, it's incredibly easier to configure,
> > and usually more reliable about output, than lprng.
> 
> Implying that there are circumstances where CUPS will produce valid output,
> and lprng will not?  I'm interested.  Examples, please.

Having not used lprng in over 3 year, I can't come up with any examples
off the top of my head.

I think you're primarily objecting to my characterization of these bugs
as lprng bugs, rather than filter bugs, which is what they probably
actually were. However, from the perspective of J. Random Enduser, it
doesn't matter if the bug is in the filter or the print server; if it
doesn't print (or prints with garbage), it doesn't print.

I'm sure if I had spent many, many more hours configuring filters for
lprng (I used apsfilter for some time with Slackware, and then changed
magicfilter shortly after moving to Debian), I could've gotten the same
quality of output with these that I got with CUPS after about 5 minutes
with its web interface.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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

Re: setgid crontab

[Steve Greenland]

On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: 
> 
> One possible gotcha is that if crontab(1) does any sanity checks of the
> crontab files, cron could expect them to be pre-sanitised, and might
> behave badly if an unsanitised file is put into place by a user.

Crontab and cron check the file with the same functions. It will fail to
load once, and since cron only reads files that have been updated, it
won't endlessly try to reload it once a minute.

Steve

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

Re: setgid crontab

[Steve Greenland]

On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: 
> (As a user, what I really want is a .crontab file in my home directory,
> so I can put it under revision control.)

One potential problem (or issue) I see with this is automounted home
directories. A file that was there while the user was logged in and then
disappeared might not have the effect you want. Or it might - I can see
arguments both ways.

The fact that the installed copy isn't local doesn't prevent you from
using version control, although it does require more discipline. Or a
wrapper around crontab, or a wicked definition for "EDITOR".

Steve

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

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   I would be enthusiastically for a list like -legal, where
>  people can go and ask for help to have packages audited, but not for
>  people rolling up policy to beat people on the head to make it so.

Perhaps your confusion stems from me using a non-normative "should" in
the draft text of the proposal. Of course a policy "SHOULD" cannot
mandate developer behavior outside a package, as I alluded to in my very
first reply to you. If that's all you're objecting to, you've chosen a
really counterproductive way to do it, since you've merely managed to
piss off me and several other people who are actually interested in
doing some work.

Bear in mind that policy appropriates perfectly common and valid English
for its own uses, and this is very easy to stumble over when writing
proposals. I for one, have a history of stumbling over it multiple times
in the past, and I expect to continue to do so until policy is fixed
to use uppercased normative words or something like that.

-- 
see shy jo


pgpxwDFKu6MrY.pgp
Description: PGP signature

Re: libraries being removed from the archive

[christophe barbe]

Ok, sorry for being rude in my previous mail. 

I understand the general problem that you are facing with KDE and
will try in the future to announce upcomming soname changes.

Concerning the removal, I don't really see the point of not removing
older libraries from unstable. Most of the time, rebuilding the package
is enough to fix the UNINSTALLABLE problem. 
My understanding of what you want is some kind of direct upload to 
testing which is not the intented purpose of unstable.

Btw a new libgphoto2 is comming soon ;-)

Christophe

On Sun, Aug 03, 2003 at 05:16:59PM -0500, Chris Cheney wrote:
> On Sun, Aug 03, 2003 at 05:31:37PM -0400, christophe barbe wrote:
> > You are kidding right?
> > 
> > I have not removed an old library, I have uploaded a newer upstream with
> > a different soname. That's the way it works, a new library is uploaded,
> > then packages using it are rebuilt and when they are all ready they
> > migrate in testing. 
> > 
> > As the gphoto2 maintainer, I don't remember getting mails from you
> > announcing an upcoming libusb package with a new soname. Perhaps that's
> > because I was waiting for a few months to get a working one for our
> > powerpc users.
> > 
> > IMHO we need to make an addition to the policy stating that not being an
> > asshole on the mailing-list is welcome. I don't remember sending mails
> > to the mailing list when the libusb packaging was broken for a few
> > months, but I do remember sending you polite mails.
> > 
> > For you information, some packages using libexif need libexif9.
> > I agree that I could (should) have sent a prior notice before uploading it 
> > (more than a week ago, BEFORE your kdegraphics upload), but that's not
> > an excuse to be an asshole.
> > 
> > Christophe
> 
> You aren't the only one that has broken things, many other people
> including myself have as well, I most notably with libvorbis ;). However,
> this libusb soname change you mention last happened on Feb 27 2002,
> which was changed due to a RC bug regarding its naming. (BTW libusb's
> soname is odd, which is why I didn't catch it sooner). Also you mention
> that libusb was broken for several months, which is true, but it was
> only broken on one arch (powerpc).  Also, from what I can tell from
> looking back at it by the time you determined it wasn't a bug in
> gphoto2 you NMU'd it within a week. I don't recall if I was actually
> aware of the bug before you NMU'd it.
> 
> Also, I was not stating that libexif9 should not be uploaded, only that
> old libraries should not be removed from the archive until they are no
> longer used, which apparently was not the case for libexif8. I don't
> recall if I stated this earlier but each time I have uploaded KDE in the
> past several months it has been broken by library removals within about
> a week and recompiling KDE sources is not light work for the buildds.
> 
> Seriously, if we want to ever release sarge we are going to need to stop
> making libraries disappear, every time we rebuild something it takes
> another 10 days for it to migrate into testing and everything that
> depends on it is also pushed back another 10 days. Even if the person
> causing the breakage NMU's all the affected packages it still causes
> them to wait another 10 days to migrate, and causes unneeded load on
> the buildds, possibly with the packages no longer being able to be
> built since gcc 3.3 is so anal now. (/me wonders how many RC bugs are
> around just for gcc 3.3 related crap)
> 
> BTW - For those wondering Woody was released over a year ago...
> 
> Thanks,
> 
> Chris Cheney
> 
> PS - I apologize for sounding like an asshole, however this general
> problem really does need fixing.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

Cats seem go on the principle that it never does any harm to ask for
what you want. --Joseph Wood Krutch

Re: setgid crontab

[Russell Coker]

On Mon, 4 Aug 2003 08:25, Steve Greenland wrote:
> On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> > (As a user, what I really want is a .crontab file in my home directory,
> > so I can put it under revision control.)
>
> One potential problem (or issue) I see with this is automounted home
> directories. A file that was there while the user was logged in and then
> disappeared might not have the effect you want. Or it might - I can see
> arguments both ways.

Also you don't want the main copy of cron to search auto-mounted user home 
directories.  If you do that then a failure of the NFS server will put cron 
in "D" state...

-- 
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: Bug#203653: ITP: autoconf-archive -- The GNU Autoconf Macro Archive

[Roger Leigh]

Martin Godisch <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Version: N/A; reported 2003-07-31
> Severity: wishlist
>
> * Package name: autoconf-archive
>   Version : 20030521
>   Upstream Author : 
> * URL : http://www.gnu.org/software/ac-archive/
> * License : GPL2 with exception [1]
>   Description : The GNU Autoconf Macro Archive

FYI: there happen to be two versions of the ac-archive.  The GNU one
is the official one, but there is a fork maintained on SourceForge.
The latter (last time I checked) had a more macros in it, and was more
up-to-date.  It may now be the case that they are co-ordinating
better, but there was some disagreement between the maintainers, which
led to the initial fork.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers

Re: libraries being removed from the archive

[Thomas Viehmann]

Chris Cheney wrote:
...
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9.  Guess what that does... any package which depends on libexif8
...
> not be removed from the archive until no other packages still depend on
> it.

Well, if it's uninstallable for a couple of days, does it matter that much?
My guess is that while it would be nice to have other ways dealing with this,
your suggestion would create a ton of problems for maintainers to have to follow
too many old versions of their packages.
In your particular case, the problem seems to be 'grep Package
kdegraphics-3.1.3/debian/control  | wc -l' generating large build-dependencies.
(And yes, I know that this is a design decision by upstream.)
Usually recompiling for soname-changes should not be that big a problem.
I'd rather a slower development process than many packages depending on obsolete
versions of libraries during shipping.

Cheers

T.

P.S.: I was today hit by #199049 when wanting to reinstall my system, so I've
been thinking about library packages 'disappearing' and recompiling of stuff
today (or yesterday, really).


pgpgsh3IDi0GM.pgp
Description: PGP signature

Re: libraries being removed from the archive

[Steve Langasek]

On Mon, Aug 04, 2003 at 01:37:43AM +0200, Thomas Viehmann wrote:
> Chris Cheney wrote:
> ...
> > for example libexif8 was removed by Christophe Barbe and replaced by
> > libexif9.  Guess what that does... any package which depends on libexif8
> ...
> > not be removed from the archive until no other packages still depend on
> > it.

> Well, if it's uninstallable for a couple of days, does it matter that much?
> My guess is that while it would be nice to have other ways dealing with this,
> your suggestion would create a ton of problems for maintainers to have to 
> follow
> too many old versions of their packages.

The problem, which is a very real one, is this:

- large application at the top of the dependency change is uploaded.
- library it depends on has an soname bump before the application makes
  it into testing.
- bug is filed against the application, because it's now uninstallable
  on sid.
- recompiled application is uploaded; testing counter resets.

That said, I don't think Chris's recommendation is the right one.  In
one sense, the status quo results in a strong incentive for application
maintainers to "trim the fat" from their dependency trees.  Moreover,
requiring library maintainers to maintain multiple copies simultaneously
seems rather extreme, for issues that really only apply to a subset of
packages.

I think a better approach would simply be to regard application
uninstallable-in-sid bugs as non-RC for testing purposes.  Since the
testing scripts will already refuse to process new libs that render
applications uninstallable, the only impact here will be that certain
packages will be uninstallable on a new, completely pristine unstable
system -- which, frankly, is not a significant concern of mine.
(Putting both testing and unstable in sources.list works just fine,
IME.)  Tagging such bugs appropriately and ignoring them until after the
application makes its way into testing would probably serve our release
process better than worrying about uninstallability problems caused by
versions of packages which are themselves not yet release candidates.

-- 
Steve Langasek
postmodern programmer


pgphoxRZRksQg.pgp
Description: PGP signature

run-parts problem again

[Martijn van Oosterhout]

Way back when Russel Coker reported a problem with run-parts in woody
(message-id <[EMAIL PROTECTED]>, 3 Jan 2003). We've
been experiencing this problem quite regularly such that I've created a cron
job to automatically kick them along.

In any case, the above thread suggested the problem was fixed in
proposed-updates. Any ETA on that being merged with woody or should I grab
the file from p-u?
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> "All that is needed for the forces of evil to triumph is for enough good
> men to do nothing." - Edmond Burke
> "The penalty good people pay for not being interested in politics is to be
> governed by people worse than themselves." - Plato


pgpKDzoZR5KkW.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 18:53:34 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> I would be enthusiastically for a list like -legal, where people
>> can go and ask for help to have packages audited, but not for
>> people rolling up policy to beat people on the head to make it so.

> Perhaps your confusion stems from me using a non-normative "should"
> in the draft text of the proposal. Of course a policy "SHOULD"
> cannot mandate developer behavior outside a package, as I alluded to
> in my very first reply to you.

Well, when someone proposes a patch to policy, with a properly
 created patch against current policy, then of course the normal
 assumption is that the person was using should as policy normally
 does. How can one tell otherwise?

> If that's all you're objecting to, you've chosen a really
> counterproductive way to do it,

Really? I recall starting off with a question. I said this
 seems like a good practice kind of thing, and whether it should be
 dev reference material. Just the thing to get people pissed off, eh?

I followed up with mentioning that it was not just nethack,
 other games were also affected, and that, unlike the implication in
 the original patch, there was more than discussion required, help
 would be needed to modify programs if setgid was not acceptable.

So far, I am 6-7 mails into the discussion, and I have been
 quiet, polite  and asking for explanations.

Then you brought up a bunch of examples about recommendations
 in policy, and I pointed out that those cases were different, since
 program code and behaviour, or program design, were often not
 involved. Then mdz said something about this is all just packaging,
 and I protested. 

So far, I fail to see what exactly has been said (until the
 disingenuous remark) that is so very counterproductive.

Perhaps I was not so off the mark when I talked about chips on
 the shoulder?

I note that later discussion tried to paint this whole process
 as getting people involved in auditing code, and not a mandatory
 requirement (ie, if you do not get a consensus then your package is
 buggy) that was in the original proposal.

I have a full log of this email conversation, as indeed do the
 list archives, so just go back and lok the whole thread up.

> since you've merely managed to piss
> off me and several other people who are actually interested in doing
> some work.

If I pissed you folks off, then rest assured that the contrary
 was also true, but I am not going to whine about people on this
 mailing list annoying me or hurting my poor, beleaguered ego.  The
 conversation degenerated due to little jabs and pin pricks from all
 around; which unfortunately seems to be the cost of doing business in
 this mailing list -- unless, of course, you muzzle your own opinions
 and follow the herd.

So either get a thicker skin, or do not expect petulant mails
 to me to not get the treatment they deserve. I always start of
 politely, and would never get confrontational unless in reaction (hi
 aj). 

As for doing work in reviewing packages, I would not be
 disinclined to do so -- though that was a neat jab, couching this
 disagreement in terms of crusty old loafer pissing off the hard
 working folks.


> Bear in mind that policy appropriates perfectly common and valid
> English for its own uses, and this is very easy to stumble over when
> writing proposals. I for one, have a history of stumbling over it
> multiple times in the past, and I expect to continue to do so until
> policy is fixed to use uppercased normative words or something like
> that.

Well, If this proposal was in plain text, not a properly
 formed patch against current policy, and thus meant to be interpreted
 in the context of the policy document, perhaps that would have been
 clearer.

manoj
-- 
One good reason why computers can do more work than people is that
they never have to stop and answer the phone.
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: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   I note that later discussion tried to paint this whole process
>  as getting people involved in auditing code, and not a mandatory
>  requirement (ie, if you do not get a consensus then your package is
>  buggy) that was in the original proposal.

Fundamentally you make a wrong assumption. If policy requires that
"developers MUST hop on one leg while uploading packages", and someone
catches me sitting down during a long upload, a bug on my package will
do nothing to correct that, and will be "fixed" by a bit-identical
upload made in the privacy of my own home (while lying down, probably).
Policy cannot mandate developer behavior outside the strings of bits
we're allowed to put into Debian.

>   I have a full log of this email conversation, as indeed do the
>  list archives, so just go back and lok the whole thread up.

It'd be great if you'd use your archive to read the thread and motivatons 
that led up to the draft proposal before you try to falsly accuse us
as you do in the first paragraph I've quoted.

>   Well, If this proposal was in plain text, not a properly
>  formed patch against current policy, and thus meant to be interpreted
>  in the context of the policy document, perhaps that would have been
>  clearer.

It was clearly marked as a draft proposal, and not a formal policy
proposal. And frankly, the thread was quite congenial and productive
until you came along.

-- 
see shy jo


pgpY92rKVwpoj.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Sun, 3 Aug 2003 22:30:52 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> I note that later discussion tried to paint this whole process as
>> getting people involved in auditing code, and not a mandatory
>> requirement (ie, if you do not get a consensus then your package is
>> buggy) that was in the original proposal.

> Fundamentally you make a wrong assumption. If policy requires that
> "developers MUST hop on one leg while uploading packages", and
> someone catches me sitting down during a long upload, a bug on my
> package will do nothing to correct that, and will be "fixed" by a
> bit-identical upload made in the privacy of my own home (while lying
> down, probably).  Policy cannot mandate developer behavior outside
> the strings of bits we're allowed to put into Debian.

Policy can make it so that packages are not accepted into
 Debian unless you hop through certain hoops. Like making sure the
 upload has a signature. Or that it has an entry in the override
 file. I can easily code an entry for katie and friends that takes a
 new package, and marks up the ones with setgid bits set -- and the
 ftp maintainers do not create override entries until they see a
 consensus develop, or the security team says ok.

For gods sake, come up with some more intelligent arguments
 for your point of view.


>> I have a full log of this email conversation, as indeed do the list
>> archives, so just go back and lok the whole thread up.

> It'd be great if you'd use your archive to read the thread and
> motivatons that led up to the draft proposal before you try to
> falsly accuse us as you do in the first paragraph I've quoted.

Are you saying that the review was not discussed as a gating
 mechanism? If that is the case, then I admit I, for one, was fooled.

Message-ID: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
 >> All set[ug]id setups should be reviewed before they go into the
 >> archive. 

Sounds like this has more teeth than hopping on one leg. And,
 unlike things like how many legs one is standing on.

>> Well, If this proposal was in plain text, not a properly formed
>> patch against current policy, and thus meant to be interpreted in
>> the context of the policy document, perhaps that would have been
>> clearer.

> It was clearly marked as a draft proposal, and not a formal policy
> proposal. And frankly, the thread was quite congenial and productive
> until you came along.

Sure. As long as there is no dissent, or disagreement,
 everything is cosy and hunky dory. The first sign of disagreement,
 though, the whole congeniality things frays apart.

The idea is not to only be nice and freindly to yes men, but
 also to be able to discuss rationally with people who do not share
 your view, without bringing in ridiculously insulting strawmen like
 hopping on one foot.

manoj
-- 
Immigration is the sincerest form of flattery. Jack Paar
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: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   Policy can make it so that packages are not accepted into
>  Debian unless you hop through certain hoops. Like making sure the
>  upload has a signature. Or that it has an entry in the override
>  file.

No, those have nothing to do with policy and are implemented solely at
the ftp master's discretion. If I had intended to "gate" setuid binaries
from debian, I would have posted to debian-cabal, not debian-devel.

>   Are you saying that the review was not discussed as a gating
>  mechanism? If that is the case, then I admit I, for one, was fooled.
> 
> Message-ID: <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>  >> All set[ug]id setups should be reviewed before they go into the
>  >> archive. 

Manoj, you have misquoted Matt here. After the word "archive", he put
not a period, but the rest of his sentence. If you read the whole thing:

  I absolutely support this idea.  All set[ug]id setups should be reviewed
  before they go in the archive, and I volunteer to do the review (though I
  hope that others will help).  Does this need a proposal to go into policy
  with the same force as the existing pre-depends verbiage?

Matt is here, I belive, expressing a heartfelt opinion that it would be
good for us to find security problems before they become *our* security
problems. Moreover he's volenteering to do work. If his use of "should"
was not satisfactory, well, he was not making a formal policy poposal
either. I'm willing to cut people who do work a lot more slack than those
who impede it.

>   The idea is not to only be nice and freindly to yes men, but
>  also to be able to discuss rationally with people who do not share
>  your view, without bringing in ridiculously insulting strawmen like
>  hopping on one foot.

One of my rules of thumb is to stop replying to threads when my opponents
resort to terms they learned in debating class, or to misquoting, since
nothing good ever comes of it. Bye.

-- 
see shy jo


pgprO8o86eZrS.pgp
Description: PGP signature