Re: non-setgid mail MUAs

[Manoj Srivastava]

>>"Matt" == Matt Kraai <[EMAIL PROTECTED]> writes:

 Matt> Howdy, Policy 3.2.1.0 states that MUAs should be setgid mail.
 Matt> This is so that they can create lockfiles in /var/spool/mail.
 Matt> This has the unfortunate consequence that MUA bugs can be
 Matt> exploited to read the email of other users.  A setgid mail
 Matt> locking utility has been added to liblockfile so that MUAs that
 Matt> use liblockfile do not need to be setgid mail.  I have attached
 Matt> a patch to policy.sgml to this effect.  Assuming that this is a
 Matt> reasonable request, would some developer please officially
 Matt> propose it?

I suggest we have the code inplace, and have it tested, and
 then get the MUA's to start using it _first_, and then we create
 policy.  Policy should follow tested practice, rather than lead by
 vapourware. 

manoj
-- 
 Fourth Law of Applied Terror: The night before the English History
 mid-term, your Biology instructor will assign 200 pages on planaria.
 Corollary: Every instructor assumes that you have nothing else to do
 except study for that instructor's course.
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: PLEASE: standard package README file/orientation

[Manoj Srivastava]

>>"Christian" == Christian Hammers <[EMAIL PROTECTED]> writes:

 Christian> ... to be replaced by what? The maintainers simply won't
 Christian> write manpages en mass, so when deleting undocumented(1)
 Christian> many packages will have binaries without manpage making it
 Christian> harder for newbies to find the docs -> no benefit?

What benefit does it have to be pointed to something that is
 of little help in the first place?  It is not as if the
 undocumented(1) man page actually provides any documentation, so the
 newbies are not really being helped. 

Indeed, if it were not for the undocumented(1) man page, many
 people may have more of an incentive to actually write man pages. 

How about we volunteer to create a man page for some of these
 binaries and send it in as a patch/bug to the BTS? How many man pages
 are we talking about?

manoj
-- 
 If it's working, the diagnostics say it's fine. If it's not working,
 the diagnostics say it's fine. A proposed addition to rules for
 realtime programming
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: Bug#70269: automatic build fails for potato

[Manoj Srivastava]

>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

 Joey> Well that wording has been there forever, so this cannot be a recent
 Joey> change in policy, though it could be a change in the way some people
 Joey> interpret policy.

My impression has always been that the packaging manual was
 policy. Off hand, the version number system comes to mind as being
 policy.  I have also held the opinion that there are things in the
 packaging manual that do not belong there -- they are better off as
 documentation of dpkg, in some cases. 

I think the tie has come for us to reexamine the packaging
 manual, and extract the things that ought to be policy, and let the
 other bits go to the dpkg maintianers for update.

In my opinion, we need to retain as policy 
 a) API's to the packaging mechanism that are 
 i) regarded as being standard API's, with dpkg/apt et al
providing an implementation.
ii) Used so widely that changin them would impact a majority of
packages, and should require more discussion and consensus of
more than the maintainers of one package
 b) codification of practices for which there are muyltiple,
technically equivalewnt practices, and one needs be choosen for
consistency and interoperability. 

It has been argued that nailing down all aspects of the
 behaviour of dpkg and friends is stilfling to the development and
 improvements; the counter argument has been that packages this widely
 used ought to try very very hard to be backwards compatible, and
 indeed, a change in behaviour may well be contrued to be a bug. 

manoj
-- 
 "Unlike most net.puritans, however, I feel that what OTHER consenting
 computers do in the privacy of their own phone connections is their
 own business." John Woods, [EMAIL PROTECTED]
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: non-setgid mail MUAs

[Roland Rosenfeld]

On Mon, 28 Aug 2000, Matt Kraai wrote:

> Policy 3.2.1.0 states that MUAs should be setgid mail.  This is so that
> they can create lockfiles in /var/spool/mail.  This has the unfortunate
> consequence that MUA bugs can be exploited to read the email of other
> users.  A setgid mail locking utility has been added to liblockfile so
> that MUAs that use liblockfile do not need to be setgid mail.

Please don't forget that liblockfile 1.01 (didn't see a newer version
yet) does not provide nfs-safe locking, which violates policy chapter
5.6.  So I dissuade from using liblockfile for MUAs until this problem
is solved (see Bug #43491).

Tscho

Roland

BTW: Can someone explain me, why a mailbox should has to be group mail
 writable?  Are there any MDAs, which don't run with root
 permission?  With procmail installed, I can safely change the
 mailbox files to permission 600 (owned by the user).

-- 
 * [EMAIL PROTECTED] * http://www.spinnaker.de/ *

Re: non-setgid mail MUAs

[Josip Rodin]

On Tue, Aug 29, 2000 at 10:57:43AM +0200, Roland Rosenfeld wrote:
> BTW: Can someone explain me, why a mailbox should has to be group mail
>  writable?

I think it's just an artifact, just like the sentence saying the spool
directory should be mail.mail, when we haven't been using that in ages. :)

>  Are there any MDAs, which don't run with root permission?

All that's needed is setgid mail to lock $MAIL, and permissions of the user
the mail is being delivered to to write to $MAIL. No root permissions.

>  With procmail installed, I can safely change the mailbox files to
>  permission 600 (owned by the user).

Works with maildrop, too.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Bug#70269: automatic build fails for potato

[Wichert Akkerman]

Previously Manoj Srivastava wrote:
>   I think the tie has come for us to reexamine the packaging
>  manual, and extract the things that ought to be policy, and let the
>  other bits go to the dpkg maintianers for update.

Very much agreed!

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgproxdD7RxRS.pgp
Description: PGP signature

Re: non-setgid mail MUAs

[J C Lawrence]

On Tue, 29 Aug 2000 10:57:43 +0200 
Roland Rosenfeld <[EMAIL PROTECTED]> wrote:

> On Mon, 28 Aug 2000, Matt Kraai wrote:

> BTW: Can someone explain me, why a mailbox should has to be group
> mail writable?  Are there any MDAs, which don't run with root
> permission?  With procmail installed, I can safely change the
> mailbox files to permission 600 (owned by the user).

The MDA may not be running against a local filesystem (eg NFS mount
of /var/spool/mail without root mapping).

-- 
J C Lawrence Home: [EMAIL PROTECTED]
-(*)   Other: [EMAIL PROTECTED]
http://www.kanga.nu/~claw/Keys etc: finger [EMAIL PROTECTED]
--=| A man is as sane as he is dangerous to his environment |=--

Picking apart the packaging manual (long)

[Manoj Srivastava]

Hi,

I went through the packaging manual, and these are the parts I
 think belong in policy (I had the full text for these sections in
 this message, but I was afraid it would pass the max message size
 limit). I am also ambivalent about sections like 4.1 "Syntax of
 control files". That section could be said to belong in policy, as
 dictating the standard format of control files, and any change may
 affect every package there is, on the other hand, this is merely
 needed to ensure the correct working of dpkg and friends, and not a
 policy issue. 

I am tending to lean towards the latter, andt thus have
 included 7.2, Notes about writing descriptions, but not 7.0 or 7.1,
 which are more syntax. 

==
2.4 Time Stamps
3.2.1. `debian/rules' - the main building script  *** This may need review
3.2.2. `debian/control'   ??? mandatory parts in policy?
3.2.5. `debian/files' partial, should not
  exist in shipped package
3.4.1. Restrictions on objects in source packages
 The source package
 may not contain any
 hard links, device
 special files,
 sockets or setuid or
 setgid files.

4.2.1. `Package' acceptable characters
 in names
4.2.13. `Standards-Version'
4.2.14. `Distribution'
5. Version numbering
5.1. Version numbers based on dates
6. Package maintainer scripts and installation procedure
6.1. Introduction to package maintainer scripts
6.2. Summary of ways maintainer scripts are called
6.3. Details of unpack phase of installation or upgrade
6.4. Details of configuration
6.5. Details of removal and/or configuration purging
7.2. Notes about writing descriptions
8.2. Binary Dependencies - `Depends', `Recommends', `Suggests',
 `Pre-Depends'
8.3. Alternative binary packages - `Conflicts' and `Replaces'
8.4. Virtual packages - `Provides'
8.5. `Replaces' - overwriting files and replacing packages
8.5.1. Overwriting files in other packages
8.5.2. Replacing whole packages, forcing their removal
8.7. Relationships between source and binary packages - `Build-Depends',
`Build-Depends-Indep', `Build-Conflicts', `Build-Conflicts-Indep'
12. Shared libraries
==

Comments? If this is roughly acceptable, I'll create a new
 document and present it for review.

manoj
-- 
 An expert is one who knows more and more about less and less until he
 knows absolutely everything about nothing.
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: Picking apart the packaging manual (long)

[Franklin Belew]

On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:


Can we add a section on shared objects that are merely plugins or components
of a larger program?
For example: xmms plugins, and mozilla xpcom objects

Frank aka Myth

Re: Picking apart the packaging manual (long)

[Manoj Srivastava]

>>"Myth" == Franklin Belew <[EMAIL PROTECTED]> writes:

 Myth> On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:
 >> lots of neat stuff>

 Myth> Can we add a section on shared objects that are merely plugins
 Myth> or components of a larger program?  For example: xmms plugins,
 Myth> and mozilla xpcom objects

I thik that should be a separate proposal. I was trying to
 keep the focus of this effort to separate the dpkg documentation from
 policy material, and not get distracted by any discussions on
 additions.

Please file a wishlist bug against policy expanding on your
 idea, and we shall see what we can do.

manoj
-- 
 Rainy days and Mondays always get me down.
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: Picking apart the packaging manual (long)

[Josip Rodin]

On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:
> 6.3. Details of unpack phase of installation or upgrade
> 6.4. Details of configuration
> 6.5. Details of removal and/or configuration purging

These sections surely have some technical details that the Policy doesn't
need to contain... for example, from 6.4:

   When we configure a package (this happens with dpkg --install, or with
   --configure), we first update the conffiles and then call:

postinst configure most-recently-configured-version

   No attempt is made to unwind after errors during configuration.

   If there is no most recently configured version dpkg will pass a null
   argument; older versions of dpkg may pass  (including the angle
   brackets) in this case. Even older ones do not pass a second argument at
   all, under any circumstances.

The fact that $1 and $2 currently have useful meanings matters, but what's
the behaviour of dpkg 0.93.* shouldn't matter... :)

-- 
Digital Electronic Being Intended for Assassination and Nullification

Bug#61058: #61058: FHS: /usr/local/share/man instead of /usr/local/man ?

[srivasta]

Hi,

man-db 2.3.17-1 now does the right thing, and the FHS folks
 have agreed to incorporate that in the next revision of the FHS. I do
 not think we need make policy on this. I am thus closing this, since
 this issue has been satisfactorily resolved.

manoj
-- 
 Smoking is one of the leading causes of statistics. Fletcher Knebel
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

Bug#61058: marked as done (FHS: /usr/local/share/man instead of /usr/local/man ?)

[Debian Bug Tracking System]

Your message dated Tue, 29 Aug 2000 23:24:28 -0500 (CDT)
with message-id <[EMAIL PROTECTED]>
and subject line #61058: FHS: /usr/local/share/man instead of /usr/local/man ?
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Darren Benham
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 24 Mar 2000 18:43:44 +
Received: (qmail 26763 invoked from network); 24 Mar 2000 18:43:42 -
Received: from h-62.96.128.34.host.de.colt.net (HELO pille.addcom.de) ([EMAIL 
PROTECTED])
  by master.debian.org with SMTP; 24 Mar 2000 18:43:42 -
Received: (qmail 8707 invoked from network); 24 Mar 2000 18:44:39 -
Received: from h-62.96.148.115.host.de.colt.net (HELO 
thefly.mathi.uni-heidelberg.de) (62.96.148.115)
  by pille.addcom.de with SMTP; 24 Mar 2000 18:44:38 -
Received: from 192.168.1.2 by thefly.mathi.uni-heidelberg.de with esmtp
 (MasqMail 0.0.11) id 12YYVX-2Ne-00; Fri, 24 Mar 2000 19:08:27 +0100
Received: from flight by freefly.hoffleit.org with local (Exim 3.12 #1 (Debian))
id 12YXyq-0004vn-00; Fri, 24 Mar 2000 18:34:40 +0100
Date: Fri, 24 Mar 2000 18:34:39 +0100
From: Gregor Hoffleit <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: FHS: /usr/local/share/man instead of /usr/local/man ?
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
User-Agent: Mutt/1.0.1i
X-Reportbug-Version: 0.54
Sender: Gregor Hoffleit <[EMAIL PROTECTED]>


--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Package: man-db
Version: 2.3.15
Severity: normal

I'm not sure about this, but if FHS uses /usr/share/man, shouldn't we then
also search in /usr/local/share/man, for symmetry reasons ? Currently,
manpath.config *only* has /usr/local/man, but no /usr/local/share/man, while
it has both /usr/man as well as /usr/share/man.

Gregor


-- System Information
Debian Release: 2.2
Architecture: i386
Kernel: Linux freefly 2.2.13 #1 Sat Nov 20 12:44:19 EST 1999 i586

Versions of packages man-db depends on:
ii  groff 1.15.2-1   GNU troff text-formatting syst=
em.=20
ii  libc6 2.1.3-7GNU C Library: Shared librarie=
s an
ii  libdb21:2.4.14-9 The Berkeley database routines=
 (ru

--=20
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut   PHONE: (49)6221 56-5771 |
|   INF 288, 69120 Heidelberg / Germany  FAX: 56-3812 |
| EMAIL: [EMAIL PROTECTED] (NeXTmail)|

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE426cv3eVfDf25G40RAbgKAKCeBWsr3IR65iqAbINzG1c3Ljd3XwCbBcqK
UW6To5tRIkUzBYCAPJevGiE=
=8ns3
-END PGP SIGNATURE-

--NzB8fVQJ5HfG6fxh--
---
Received: (at 61058-done) by bugs.debian.org; 30 Aug 2000 04:34:19 +
>From [EMAIL PROTECTED] Tue Aug 29 23:34:19 2000
Return-path: <[EMAIL PROTECTED]>
Received: from cm-199-3-110-122.mobile.mediacom.ispchannel.com 
(glaurung.green-gryphon.com) [:::199.3.110.122] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 13TzZq-0001tT-00; Tue, 29 Aug 2000 23:34:18 -0500
Received: (from [EMAIL PROTECTED])
by glaurung.green-gryphon.com (8.11.0/8.11.0/Debian 8.11.0-1) id 
e7U4OT614675;
Tue, 29 Aug 2000 23:24:29 -0500
X-Mailer: emacs 20.7.2 (via feedmail 9-beta-7 I);
VM 6.75 under Emacs 20.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 29 Aug 2000 23:24:28 -0500 (CDT)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: #61058: FHS: /usr/local/share/man instead of /usr/local/man ?
X-Time: Tue Aug 29 23:24:28 2000
Mail-Copies-To: never
Delivered-To: [EMAIL PROTECTED]

Hi,

man-db 2.3.17-1 now does the right thing, and the FHS folks
 have agreed to incorporate that in the next revision of the FHS. I do
 not think we need make policy on this. I am thus closing this, since
 this issue has been satisfactorily resolved.

manoj
-- 
 Smoking is one of the leading causes of statistics. Fletcher Knebel
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

Status of open topics -- comments?

[Manoj Srivastava]

Hi,

Continuing my sweep of currently open topics, I have been
 looking at the open reports in the BTS. I have tried to come up with
 opinions on the status and actions required. Since this is a long
 list, I've just started at the top, and am working my way down. Any
 comments or corrections are appreciated. 

What do people feel about periodic postings of this list to
 this mailing list, say, once a month?

manoj

normal bugs - outstanding

#47438: copyright statement needs updating?
  Status: Undecided, the only consensus was that the copyright may
  need to be changed
  Action: No clear action recommended; Julian asked a bunch of people
  to assign copyright to SPI, but nothing was done

#60979: What /etc/init.d/xxx restart does?
  status: restart stops and starts the program, perhaps we need a
  start-rc.d script  We now are waiting for code. 
  Action: Nothing, until the code is written. 
  This should be downgraded to a proposal, pending code.

#62943: debian-policy omits packaging manual
  Status: We need to incorporate policy making parts of the packaging
  manual into policy, and hand over the remnants to the dpkg
  maintainers. We are now actively in the process of deciding 
  what goes where.
  Action: decide on where to split.

#62996: no way to detect webservers without CGI support
  Action: virtual packages httpd-cgi-enabled and minimal-httpd
  implemented, shall be in the next upload

#66023: [PROPOSAL] Treat plugins and shared libraries differently
  Status: This was never formally proposed or seconded, though there
  seems to be a consensus that has emerged.
  Action: this should be proposed, seconded, and put on track for
  normal handling. 

wishlist bugs - outstanding

#11094: [PROPOSAL] Policy should mention that serial lines
require UUCP-style locking 
  Status: This may not be required, given the FHS section on how
  devices should be locked? This has lojng been stagnant, and
  may not be needed. 
  Action: Needs a sponsor.

#20373: [PROPOSAL] shouldn't start init scripts in wrong  runlevel
Status: this is the same problem as addressed in #60979. We need
code for start-rc.d 
  Action: Nothing, until the code is written. 

#27205: [GUIDELINES] Daemons should run as root only if really  needed
Status: this does not belong in policy
Action: should be marked fixed, but not closed

#32263: [PROPOSAL] Splitting cgi-bin
Status: Dead, objections
Action: Should be marked closed.

#47298: Making /usr/doc/XXX symbolic link to ../share/doc/XXX  is BAD idea
Status: Dead. 
Action: Should be marked closed? Perhaps with example scripts
which show how this can be handled? 


#48045: debian-policy: non-US is a misnomer
Status: No consensus
Action: Should be marked closed.

#51116: Suggestion: Packages should carry a manpage
#51262: Suggestion: Packages should carry a manpage
Status: Dead, objections
Action: Should be marked closed.

#51411: build-essential does not include debhelper
#51412: conflict in documents
#51473: [PROPOSED] Change package relations policy to remove
  references to non-free from main
#51702: [PROPOSED] Change package relations policy to remove
  references to non-free from main
#51842: [PROPOSED] closing hole in DFSG that can force you to
  include some text in advertisement
#51879: PROPOSAL: package may be maintained by a group
#53496: some details wrong in Policy section 3.2.
#53582: base dependency warning
#53700: bogosity in editor/pager discussion
#53849: PROPOSAL: emacs/tex downgrading to optional
#54002: [PROPOSAL] permit use of bzip2 for source packages
#54524: http_proxy and web clients.
#54985: debian-policy: handling of shared libraries
#55048: [PROPOSAL] clarify update-rc.d stuff
#55730: [PROPOSED] Changes in handling library dependencies
#57154: debian-policy: makedev
#58340: Proposal: add 'distro' control field
#59403: [PROPOSED] restrictions on content of /usr/share/doc
#60461: debian-policy: FHS conformance not explicit
#62070: Package freeze makes no sense for package
#65577: [Amended] copyright should include notice if a
  package is not a part of Debian distribution
#65578: [PROPOSED] extra-Debian packages should have extra
  Priority
#65764: changelog shouldn't be in the copyright file
#65765: a needless paragraph
#66535: proposal of virtual package: syslogd
#66912: [PROPOSAL] init script configuration variables
#69229: [PROPOSED 2000/08/16] Free pkgs depending on non-US
  should go into non-US/{main,contrib}
#69311: [PROPOSAL] Finishing the /usr/doc -> /usr/share/doc
   transition.

fixed bugs - outstanding


 #23661: [REJECTED] /usr/doc should not be accessible through
   http servers by default
 #25882: [REJECTED] U/gid 100 should be statically allocated
 #27137: [REJECTED] Clarification of non-free: packages
   encouraging donations with