Re: Bug#581434: UPG and the default umask

[Andreas Metzler]

Drake Wilson  wrote:
> Quoth Don Armstrong , on 2010-05-15 14:40:05 -0700:
>> You don't need to detect UPG setups with 100% reliability; you can
>> just do the following:

>> 1. If there a possibility of this being a UPG setup:
>>2. If this user's group has the same name and GID as the user's name and 
>> UID:

> Hrmbl.  I have existing Debian systems that use UPG with UIDs and GIDs
> decidedly non-matching.  It only takes one extra addgroup without a
> corresponding adduser in the default configuration to make the IDs go
> out of sync, 
[...]

That matches my personal experience.
argenau:~# addgroup blah
Adding group `blah' (GID 1005) ...
Done.
argenau:~# adduser nongidmatch
Adding user `nongidmatch' ...
Adding new group `nongidmatch' (1006) ...
Adding new user `nongidmatch' (1005) with group `nongidmatch' ...
[...]

Part 2 the heuristic could be changed to "names of group and user
are identical and user is the only member of the group".
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/p2h4c7-3a3@argenau.downhill.at.eu.org

Bug#581804: RFP: libcatalystx-leakchecker-perl -- Debug memory leaks in Catalyst applications

[Jason Kuri]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcatalystx-leakchecker-perl
  Version : 0.06
  Upstream Author : Florian Ragwitz , Tomas Doran

* URL : http://search.cpan.org/dist/CatalystX-LeakChecker/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Debug memory leaks in Catalyst applications

CatalystX::LeakChecker tries to assist developers with finding memory
leaks in Catalyst applications by automatically checking for common
causes of leaks.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktil9-xcljowd1vwqxzwtp12fqdazxydsjmv4n...@mail.gmail.com

Re: Bug#581434: UPG and the default umask

[Drake Wilson]

Quoth Don Armstrong , on 2010-05-15 14:40:05 -0700:
> You don't need to detect UPG setups with 100% reliability; you can
> just do the following:
> 
> 1. If there a possibility of this being a UPG setup:
>2. If this user's group has the same name and GID as the user's name and 
> UID:

Hrmbl.  I have existing Debian systems that use UPG with UIDs and GIDs
decidedly non-matching.  It only takes one extra addgroup without a
corresponding adduser in the default configuration to make the IDs go
out of sync, I think---or at least that's what I've observed with both
lenny and current sid.  I kind of doubt testing numeric ID equivalence
between those two namespaces is a good idea.

   ---> Drake Wilson


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515231529.ga31...@drache.begriffli.ch

Re: UPG and the default umask

[Russ Allbery]

Roger Leigh  writes:
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:

>> That's a good idea.  I'm not sure if all UNIX group systems allow one
>> to ask how many users are a member of a particular group, but if
>> there's a way to ask that question at least in those group systems that
>> support it, the implementation should be fairly straightforward.

> The standard getgrnam/getgrgid (or the _r variants) are competely
> portable and give you the list of users who are group members (so a
> simple check through the user list is quick and easy).  From the shell
> "getent group $group" should return an empty user list.

I was thinking more in terms of access restrictions than APIs.  Being able
to ask who is a member of a particular group is a potential privacy
violation, so I wasn't sure if there were group systems in widespread use
that would refuse to tell you any information about anyone other than
yourself unless you had root or similar elevated credentials.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bpcgpxkg@windlord.stanford.edu

Re: UPG and the default umask

[Roger Leigh]

On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
> Willi Mann  writes:
> > Russ Allbery wrote:
> 
> >> The purpose of UPG is not to use the user private group for any sort of
> >> access control.  Rather, the point is to put each user in a group where
> >> they're the only member so that they can safely use a default umask of
> >> 002 without giving someone else write access to all their files.
> 
> > Is it possible to detect whether an account is configured properly based
> > on the UPG idea? If yes, wouldn't it then make sense to only set umask
> > 002 if a proper UPG account is detected, otherwise 022? This would avoid
> > putting non-UPG systems on danger.
> 
> That's a good idea.  I'm not sure if all UNIX group systems allow one to
> ask how many users are a member of a particular group, but if there's a
> way to ask that question at least in those group systems that support it,
> the implementation should be fairly straightforward.

The standard getgrnam/getgrgid (or the _r variants) are competely
portable and give you the list of users who are group members (so a simple
check through the user list is quick and easy).  From the shell
"getent group $group" should return an empty user list.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Russ Allbery]

Willi Mann  writes:
> Russ Allbery wrote:

>> The purpose of UPG is not to use the user private group for any sort of
>> access control.  Rather, the point is to put each user in a group where
>> they're the only member so that they can safely use a default umask of
>> 002 without giving someone else write access to all their files.

> Is it possible to detect whether an account is configured properly based
> on the UPG idea? If yes, wouldn't it then make sense to only set umask
> 002 if a proper UPG account is detected, otherwise 022? This would avoid
> putting non-UPG systems on danger.

That's a good idea.  I'm not sure if all UNIX group systems allow one to
ask how many users are a member of a particular group, but if there's a
way to ask that question at least in those group systems that support it,
the implementation should be fairly straightforward.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eihcc0hq@windlord.stanford.edu

Re: Bug#581434: UPG and the default umask

[Don Armstrong]

On Sat, 15 May 2010, Andreas Metzler wrote:
> #4 We cannot reliably detect UPG-setups. (The setting
>   USERGROUPS=yes/no in /etc/adduser.conf is not relevant, e.g. in a
>   NIS szenario users are generated on the master system.)

You don't need to detect UPG setups with 100% reliability; you can
just do the following:

1. If there a possibility of this being a UPG setup:
   2. If this user's group has the same name and GID as the user's name and UID:
  3. default umask of 0002
4. otherwise, default umask of 0022

In cases where you make a mistake and this isn't a UPG setup, step #2
should stop you if this is actually going to be a problem (and not
coincidentally, this is the check that pam_umask already does when you
give it the usergroups option.)

You can figure out #1 by whether or not adduser.conf is set to use
USERGROUPS, and if it is, the default for pam should probably[1]
default to adding "session optional pam_umask.so usergroups" to
common-session.

Alternatively, #2 can be done in /etc/profile using id, which should
work just fine, even on NIS setups.


Don Armstrong

1: Steve will hopefully correct me if I'm mistaken here.
-- 
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
 -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515214005.gm8...@teltox.donarmstrong.com

Re: Bug#581434: UPG and the default umask

[Thomas Hochstein]

Christoph Anton Mitterer schrieb:

>> #2 UPG with umask 022 is useless.
> Why is it?

See .


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ldd.1005152055.1...@thorondor.akallabeth.de

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Manoj Srivastava]

On Fri, May 14 2010, Scott James Remnant wrote:

>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that has to be audited.  There have
>> been patches proposed, and semi-rejected b the upstart folks, who are
>> of the opinions that only systems using initramfs need apply.
>> 
> Have to jump in here, but this is simply not true.
>
> I have never rejected any SELinux patches for Upstart; I have simply
> never been *sent* any.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10


> I've always said I'm quite happy to sit down with the SELinux folks and
> work out the right way to do this.

We can start with:
http://etbe.coker.com.au/2008/07/24/se-linux-policy-loading/

manoj
-- 
The first is to ensure your partner understands that nature has root
privileges - nature doesn't have to make sense. -- Telsa Gwynne
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrv4zxiz@anzu.internal.golden-gryphon.com

Re: UPG and the default umask

[Willi Mann]

Hi!

Russ Allbery wrote:
> The purpose of UPG is not to use the user private group for any sort of
> access control.  Rather, the point is to put each user in a group where
> they're the only member so that they can safely use a default umask of 002
> without giving someone else write access to all their files.  Then, the

Is it possible to detect whether an account is configured properly based on 
the UPG idea? If yes, wouldn't it then make sense to only set umask 002 if a 
proper UPG account is detected, otherwise 022? This would avoid putting non-
UPG systems on danger. 

WM


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hsn1gf$cs...@dough.gmane.org

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Steve Langasek]
> Was this request ever actually made to the kfreebsd porters?  I'm not sure
> that it was, in which case it's rather unfair to say that they've had enough
> time when they were never informed this was a pressing issue.

One request was done last summer, see
http://lists.debian.org/debian-bsd/2009/07/msg00117.html >.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl7hn4g9wr@login2.uio.no

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Steve Langasek]

On Sun, May 09, 2010 at 06:09:10PM -0700, Manoj Srivastava wrote:
> > In speaking with upstart upstream, I understand that the argument against
> > linking to libselinux is that, as the kernel is neutral wrt the choice of
> > LSM, the init process should be also.  Linking it against libselinux would
> > not be LSM-neutral.

> Could you perhaps expand on this a bit? The patch I submitted by
>  no means makes upstart require SELinux, nor does it preclude supporting
>  other security modules. Indeed, any other LSM support that is needed
>  can still be patched in. I think that we could get an upstart that
>  support all LSM's natively, as opposed to supporting none, at very
>  little added in the way of maintenance overhead.

Given the difference in how kernels vs. init daemons are usually
administered as part of a system, I think the runtime impact of supporting
multiple LSMs in init is much more significant than supporting multiple LSMs
in the kernel.  I don't think we want init to have shared lib deps for each
of the available LSMs.

> > And you don't have to use an initramfs; the same result could be
> > achieved with a shim init on the root filesystem that does nothing but
> > set up the SELinux context correctly and then exec upstart.

> err, does that mean sham init?

"shim" is the word I mean.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Steve Langasek]

On Sun, May 09, 2010 at 03:10:15AM +0200, Marco d'Itri wrote:
> On May 07, Julien Cristau  wrote:

> > >  - a decision to drop kfreebsd as a release architecture
> > Since 1 and 2 aren't happening, I think we should consider going with
> > the third option.
> Me too, I believe that the people interested in kfreebsd-* have had more
> than enough time to provide the compatibility framework and we cannot
> hold back Debian forever for the benefit of a toy port.

Was this request ever actually made to the kfreebsd porters?  I'm not sure
that it was, in which case it's rather unfair to say that they've had enough
time when they were never informed this was a pressing issue.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#581760: ITP: myscreen -- A tab system and display system statistics for screen

[Reinhard Tartler]

On Sat, May 15, 2010 at 17:59:37 (CEST), Clément Mondon wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "Clément Mondon" 
>
>
> * Package name: myscreen
>   Version : 0.7
>   Upstream Author : Clément Mondon 
> * URL : http://www.clement-mondon.fr/myscreen
> * License : GPL
>   Programming Lang: C
>   Description : A tab system and display system statistics for screen
>myscreen is a configuration of screen, a full-screen window
>manager that multiplexes a physical terminal.
>myscreen include screen configuration file and a program
>that provides several statistics.
>Configuration file allows to enable hardstatus bar in the
>manner of a tab system of graphical terminal.
>The program myscreen-stats provides several informations :
>number of users connected, uptime, upload and download rate,
>wifi quality, loadaverage, number of processes, cpus, disks,
>ram and swap.
>  
>myscreen-stats was written in C unlike ubuntu's package
>named screen-profiles.

is this intended to be part of the description? If yes, I'd suggest to
drop it, because:

 - it has been renamed to byobu
 - the package is in debian as well
 - is the implementation helpful information to decide which of the two
   more appropriate for a given usecase?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87632p6k3l@faui44a.informatik.uni-erlangen.de

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Aaron Toponce]

On 05/15/2010 10:47 AM, Santiago Vila wrote:
> On Sun, 16 May 2010, Charles Plessy wrote:
> 
>> Also, I have not seen on -devel that the idea of having a different
>> umask for system and regular users has been implemented in
>> base-files yet. I propose to not mention this until base-files is
>> updated to support it.
> 
> The file /etc/profile is only read for login shells, or shells that
> pretend to be login shells.
> 
> Do we really have to make /etc/profile more complex to deal with
> system users who login to the system?
> 
> Are there any? (other than root, who already has its Private Group).
> 
> Is it ok at all that a system user does a login to the system?

The root account is the only account that is a system user/group that is
a private group. The rest should not have login shells, that I
understand, so setting the umask system-wide shouldn't be a problem.
However, we do have the "staff" group, which is a system group and the
"users" group at GID 100. Both of these, I'm assuming come from
historical UNIX? Should their umask be 0022? Or do they have a different
purpose? Just making sure all of our bases are covered with this change.
I think we all want as little surprises as possible.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Santiago Vila]

On Sun, 16 May 2010, Charles Plessy wrote:

> Also, I have not seen on -devel that the idea of having a different
> umask for system and regular users has been implemented in
> base-files yet. I propose to not mention this until base-files is
> updated to support it.

The file /etc/profile is only read for login shells, or shells that
pretend to be login shells.

Do we really have to make /etc/profile more complex to deal with
system users who login to the system?

Are there any? (other than root, who already has its Private Group).

Is it ok at all that a system user does a login to the system?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005151837320.18...@kolmogorov.unex.es

Re: Open then gates

[Tollef Fog Heen]

]] Christoph Anton Mitterer 

(Please respect my mail-followup-to, there's no need to Cc me on lists
which I read.  It'd also make your mails more readable if you leave a
blank line between what you quote and your reply.)

| On Sat, 2010-05-15 at 09:04 +0200, Tollef Fog Heen wrote:
| > You can make that argument for just about all the daemons that are
| > shipped in the distro.
|
| Yes :)

Taking your line of arguments to its extreme conclusion, we should
neuter all daemons so they just exit(0) and the admin has to work out
what's wrong and fix it, since that'll be more secure as you can't
exploit any bugs they have, given they're not running.

While a system that's powered off, disconnected, covered in concrete and
guarded by well-paid and armed guards is fairly secure, its
functionality is also fairly close to zero.  I'd much rather have a
functional system that's slightly less secure.  If you'd rather have
something more secure and (IMO) less functional, I suggest you run
OpenBSD rather than Debian.

| > Should ssh not start by default or just listen
| > to localhost for instance?
|
| Personally,... I'd prefer the listen to localhost only (per default)
| solution.

I have trouble taking such a suggestion seriously.

| But I'm aware that such behaviour is probably disliked by the majority.
|
| Nevertheless,... when installing openssh-server,... you're already
| actively deciding to do so...

Not necessarily.  Maybe you're just installing convirt to manage your
Xen hosts.  Or rancid, to manage your cisco routers.  Actions have side
effects.  If you're not paying attention the side effects of admin
decisions, then well, you'll make stupid mistakes sooner or
later. Usually sooner.

| But the 002 would be shipped per default...

Yes, and you'd have to actively do something stupid (put other users
into a private group) to make this be a problem of any kind.

| > Me, I'd rather we stopped shipping /etc/default/* files with
| > ENABLE=NO and similar silliness – if you want to disable a daemon
| > (or it should not be enabled by default), put that information into
| > the Default-Start LSB header or kill the S rcN.d links/make them
| > into K links.
|
| Well but that's just a technical issue on how to enable/disable things,
| isn't it?

No, it breaks the assumption that /etc/init.d/foo start will actually
start the daemon.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5ld6se1@qurzaw.linpro.no

Bug#581760: ITP: myscreen -- A tab system and display system statistics for screen

[Clément Mondon]

Package: wnpp
Severity: wishlist
Owner: "Clément Mondon" 


* Package name: myscreen
  Version : 0.7
  Upstream Author : Clément Mondon 
* URL : http://www.clement-mondon.fr/myscreen
* License : GPL
  Programming Lang: C
  Description : A tab system and display system statistics for screen
   myscreen is a configuration of screen, a full-screen window
   manager that multiplexes a physical terminal.
   myscreen include screen configuration file and a program
   that provides several statistics.
   Configuration file allows to enable hardstatus bar in the
   manner of a tab system of graphical terminal.
   The program myscreen-stats provides several informations :
   number of users connected, uptime, upload and download rate,
   wifi quality, loadaverage, number of processes, cpus, disks,
   ram and swap.
 
   myscreen-stats was written in C unlike ubuntu's package
   named screen-profiles.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515155937.31352.52085.report...@ptiq

Re: UPG and the default umask

[Charles Plessy]

Le Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila a écrit :
> 
> Yes, I think this change is important enough to be documented in
> release notes. You might want to mention the possible gotchas, like,
> for example, performing "scp -p" from a system with umask 002 to a
> system without UPG when there are already files with mode 664 floating
> around.

Dear Santiago and everybody,

I was glad to see that a patch has already been proposed to the release notes.
To keep track with the other changes that will help to smooth the transition,
I have created a wiki page:

http://wiki.debian.org/umask

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515152419.gi26...@kunpuu.plessy.org

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Charles Plessy]

Le Sat, May 15, 2010 at 02:16:43PM +0300, Andrei Popescu a écrit :
> The default 'umask' for new installs is changed
> ===
> 
> Starting with base-files version 5.4 the default umask for new installs 
> is 0002 instead of 0022 for regular users (system users, like the ones 
> used for various daemons and services are not affected).
> 
> The new umask is more useful on systems where normal users are by 
> default members of an own private group, which no other user belongs to.  
> Such a scheme is known as 'User Private Groups' (UPG) and has been the 
> default in Debian for several releases.
> 
> This change can however create security and/or privacy issues if the 
> system administrator is not aware of it and adds users to the private 
> group of another user. Also, in order to prevent security issues, some 
> software will detect this and refuse to operate when there are other 
> members in the user's private group and relevant files have permissions 
> as created with a umask of 0002.
> ---

Dear Andrei and DDP team,

I would like to suggest a stronger wording, that underlines that user private
groups are not designed to be shared. Also, I have not seen on -devel that the
idea of having a different umask for system and regular users has been
implemented in base-files yet. I propose to not mention this until base-files
is updated to support it.

I also propose to not mention the version of base-files where the change was
done in the release notes, since this is not relevant for stable versions.
However, I suggest that we post a very similar notice, but keeping the version
information, to the Develpers News (I will do it if nobody is faster than me).

I do not know where the announcment of the new umask default would fit the
best: in the “What's new” (major changes) section, or in the “Potential
problems”.  Or what about both?

Lastly, I mention the Securing Debian Manual below. I also have opened a bug
to update it to the latest umask default (#581753).

Have a nice week-end,

-- Charles Plessy, Tsurumi, Kanagawa, Japan


* For “What's new” (major changes):

New default 'umask' for new installs


The default 'umask' in Debian is now 0002 instead of 0022. This change takes
only effect on fresh installations, and gives write permission to the members
of the group owning the user's files (they already had read and access
permissions with the previous default). Debian uses by default the 'User
Private Groups' (UPG) scheme (URL to wikipedia), where users are members of
their own private group, that is not shared with others. The new default
simplifies the sharing of files in other (non-private) groups.


* For “Potential problems”

New default 'umask' for new installs


The new default umask of 0002 [insert a convenience link to the “What's new”
section] can surprise people used to the previous value of 0022. If the newly
installed system is sharing its files, or if its users are copying their files
to systems that are not implementing user private groups, write access could be
inadvertently given to other group members.

Also, the user private groups should never be shared with others. Instead, a
collaboration group must be created for sets of users who want to share files.
Please refer to the Securing Debian Manual (URL to section “Setting users
umasks”) for more details.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515152000.gh26...@kunpuu.plessy.org

Re: debian/watch problem due to http://code.google.com download page's link format change

[Asias He]

On Sat, May 15, 2010 at 9:27 PM, Daniel Leidert
 wrote:
>
> The URL at http://code.google.com/p/ibus/downloads/list itself tells you
> everything you need: the version number. And you have a static download
> location. So what you need to do is to rewrite the download URL to point
> to http://ibus.googlecode.com/files/ibus-$(version).tar.gz and you must
> rewrite the filename. With the above URL it will be "detail" and it
> should of course be "ibus-$(version).tar.gz".
>
> See the attached file. Maybe some redirector at qa.d.o would be easier
> for people. But the change at code.g.c itself doesn't affect your
> ability to check and download the latest source file.

Thanks, Daniel. It works for me.

-- 
Best Regards
Asias He


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinfnidpuydq58vbxcfjlxbwy1imva68gzmdx...@mail.gmail.com

Re: Open then gates

[Aaron Toponce]

On 05/15/2010 02:00 AM, Robert Klotzner wrote:
> Also as far as I understood from a previous post, this change will only 
> affect 
> new installations, not existing ones. So even if a user misunderstood the 
> concept and added other users to his private group, this change does not 
> affect 
> him.  If the change is documented in the release notes and in the 
> installation 
> manual of squeeze, I do not see any problems.  Of course you can assume that 
> the user does not read them and just does stupid things, but this is an 
> entirely different issue, you can never secure a system against mindless 
> administrators, no way.

There are no security problems with this change, and you understand
correctly- this will only be implemented on new installs. If the
administrator is adding users to private groups, the it's the fault of
the administrator making bad choices on the system, not the fault of Debian.

> So I see your argument about not to be thought of side effects, but the 
> concept 
> as such is proved already and the only harm could arise from systems where 
> users assume the old umask still to be in effect when they update to squeeze 
> and it will, so what is the problem?

There isn't a problem. The ones starting this thread are reaching for
straws trying to create a problem. Sure, we'll have some apps such as
Mutt or SSH that might hiccup, and stuff like this is expected. Anytime
a change is made on the system, bugs will arise. But fixing those bugs
makes the system better than before the change was implemented. This is
a net positive win for Debian, its administrators and all those who use it.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Bug#581747: ITP: libfakefs-ruby -- A fake file system to be used in unit tests

[Tobias Grimm]

Package: wnpp
Severity: wishlist
Owner: Tobias Grimm 
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libfakefs-ruby
Version: 0.2.1
Upstream Author: Chris Wanstrath ch...@ozmm.org
URL: http://github.com/defunkt/fakefs
License: MIT
Description: A fake file system to be used in unit tests (ruby1.9.1)

FakeFS allows you to unit-test file system calls without actually touching
the file system. File, Dir and FileUtils calls are redirected to a fake
file system without requiring to use any mocking library thus making it
faster and easier to test file system calls.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4beea329.50...@e-tobi.net

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Aaron Toponce]

On 05/15/2010 05:50 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
>> This paragraph should be accompanied by something like:
>>
>> Instead of adding users to other users private groups (which has issues as 
>> explained above) it is recommend to create dedicated groups for these users 
>> for collaboration. 
> Perhaps I'm completely stupid,... but why do we have UPGs then at all?

User private groups are NOT intended to add other users too. That's why
it's called "private". The motivation behind creating a UPG setup was to
have more flexible group collaboration, without sacrificing security on
the system, or changing how standard UNIX permissions work. This has
been discussed already.

> For those rare cases like "a user's wife/husband" which is fully
> trusted?

Personally, I trust my wife, and have no problem adding her to my own
private group. However, it still is better to create a different group,
add both myself and her too, and use that to share the files. There may
be a time, when I am shopping online, or working on something I don't
want my wife to see, so putting her in my private group might have been
a mistake. Even if I fully trust how she'll handle those files.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: [OT] Re: Open then gates

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote:
> You might be interested in monkeysphere
...and in RFC 5081

I haven't had a detailed look on monkeyspehre so far, but it seemed at a
first glance, that it does not use standardised technology, does it?

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 15:59 +0300, Andrei Popescu wrote:
> By default:
> 
> # grep umask .bashrc
> umask 022
> #
Not in the most recent version of base-files, which does not update most
of it files.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Aaron Toponce]

On 05/15/2010 05:26 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
>> for regular users
> Would have to double check it,... but doesn't the current change also
> affect root?

This does, but root is also in his own UPG. If you add any user to the
root group (same this as using wheel on other systems), you're
effectively giving that user full root access to the system anyway. So,
this change will not have any unsavory side effects for the root user or
group.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: debian/watch problem due to http://code.google.com download page's link format change

[Daniel Leidert]

Am Samstag, den 15.05.2010, 17:16 +0800 schrieb Asias He:

> Recently, code.google.com changed the download page link format.
> As a result, the old debian/watch file in packages whose upstream source code
> hosted on code.google.com did work anymore.
> 
> Take the ibus project for example:
> $ cat ibus/debian/watch
> version=3
> http://code.google.com/p/ibus/downloads/list \
> http://ibus.googlecode.com/files/ibus-([0-9].*)\.tar\.gz
> 
> The new download page contain the "detail" link, one has to follow
> the new "detail" link in order to find the real download url.
> something like this:
> http://code.google.com/p/ibus/downloads/list
> http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q=
> http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz
> 
> I believe this problem affects all the packages whose upstream source
> code is hosted on code.google.com.
> 
> Is there an easy way to deal this.

The URL at http://code.google.com/p/ibus/downloads/list itself tells you
everything you need: the version number. And you have a static download
location. So what you need to do is to rewrite the download URL to point
to http://ibus.googlecode.com/files/ibus-$(version).tar.gz and you must
rewrite the filename. With the above URL it will be "detail" and it
should of course be "ibus-$(version).tar.gz".

See the attached file. Maybe some redirector at qa.d.o would be easier
for people. But the change at code.g.c itself doesn't affect your
ability to check and download the latest source file.

PS: The same BTW goes for sf.net! I would prefer if the necessary
(automatic) rewrites would be added to uscan (maybe as modules) and not
via redirectors. They are not necessary for sf.net nor code.g.c. But
that's my opinion.

Regards, Daniel


watch.ibus
Description: application/fluid

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Julien Valroff]

Le samedi 15 mai 2010 à 15:59:40 (+0300), Andrei Popescu a écrit :
> Date: Sat, 15 May 2010 15:59:40 +0300
> From: Andrei Popescu 
> To: debian-devel@lists.debian.org
> Cc: 581...@bugs.debian.org
> Subject: Re: Bug#581729: [SQUEEZE] Document the umask change for new
>  installs
> 
> On Sat,15.May.10, 13:26:29, Christoph Anton Mitterer wrote:
> > On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
> > > for regular users
> > Would have to double check it,... but doesn't the current change also
> > affect root?
> 
> By default:
> 
> # grep umask .bashrc
> umask 022
> #

This entry is commented by default in /usr/share/base-files/dot.bashrc

This file is simply copied to /root/.bashrc in base-file postinst script.

Cheers,
Julien

--
Julien Valroff 
http://www.kirya.net
GPG key: 4096R/290D20C5 
092F 4CB5 5F19 E006 1CFD  B489 D32B 8D66 290D 20C5



signature.asc
Description: Digital signature

Re: Open then gates

[Harald Braumann]

On Sat, May 15, 2010 at 12:53:30PM +0200, Christoph Anton Mitterer wrote:
> On Fri, 2010-05-14 at 22:22 -0700, Russ Allbery wrote:
> > These are really odd complaints to bring against Debian given that these
> > are not Debian issues.  Firefox, for example, works exactly the same way
> > everywhere.  What do you want Debian to do, write our own web browser?
> > There are limits to what a distribution can do.
> Again, these are just example where things could be secured
> I do of course not want to Debian write it's own browser, but we already
> patch some of them "quite heavily", don't we?
> E.g. firefox to support all the plugin-packages stuff?

So your argument is, that it must be insecure because other things are
insecure? 

> > For example, here, you don't appear to understand that we're talking about
> > the user umask, which should not be affecting system services,
> "should not"... well... I guess this  isn't a proof, is it?

You claimed that it would, so it is up to you to prove you're right,
not the others to prove you're wrong.

> We've had so many examples of things that happened although they should
> not.
> udisks should have probably not exported the dm-crypt keys to normal
> users, but it did.
> Many scripts (don't remember a concrete example now) should have
> probably set a secure PATH, but they forgot to do so, and were
> attackable.
> sudo should have probably been secure, but it wasn't and if we would
> have added normal users to sudoers (like Ubuntu does as far as I know),
> "everything" would have been vulnerable.
> The openssl issue should have probably just solved some valgrind errors
> (wasn't that the idea of those patches?) but it lead probably to the
> great disaster in cryptography in the last years...

Again, a random list of problems that have no correlation whatsoever
with UPG and umask.

> > If regular users can add other people to groups on your system, you have
> > way more serious security problems than user-private groups, and those
> > security problems are not created by Debian.
> Of course I talk about having this done by root.
> It seems you do not have experience with systems with several thousands
> of users, do you?
> If I'm e.g. a root user at my university, or an empowered registration
> authority for CERN,... I really cannot check whether what my users ask
> is sane.
> If user B says, please add user A to my group... I'll do it as long as
> no system user/group is involved.

So your argument against something that is secure by default is that
you could make it insecure by doing a really brain-damaged thing? Of
course having a umask of 022 doesn't really prevent you from doing
stupid things, so I don't see how it would improve security in this
specific instance.

> Not to talk about the fact what happens, if at one day one wants to move
> away from UPGs...

Right, lets not talk about that, because it is completely irrelevant
for the current discussion.

> > And here, you appear to have completely misunderstood the purpose of
> > user-private groups in exactly the way that I tried to explain earlier.
> > If there is anyone in a user-private group other than the user
> > corresponding to it, you have broken user-private groups and created a
> > security hole on your system.
> Yes I know... (the concept of them is really not so difficult to
> understand, is it?)
> 
> > But that's your misconfiguration, not
> > something Debian did.
> Honestly,... real world is different... see my example above in big
> organisations, consider the fact that users have typically no idea what
> they doing...

That's why they don't have the rights to change their group. If root
has so little idea of what he's doing that he adds other users to a
UPG, then quite honestly he should consider the possibility that he
has chosen the wrong line of work.

> And even if you don't consider...
> What we had now, was already kind of semi-UPGs wasn't it?
> - Everybody had his private group, which others could be added to.

No. You never add others to a UPG. So the following points are moot.

> - But if others were added, they did not automatically have rwx-rights
> on basically everything.
> 
> With a default of 022:
> The owner of the file has to manually decide to make a file writeable by
> the members of his UPG, right?
> Isn't that much secure as the other way round?
> 
> With a default of 077:
> It'd be even better, as the owner does not only have to deliberately
> decide for write, but also for read rights.
> 
> 
> > and every distribution picks something and leaves that to site policy,
> > rightfully.  022 is the "standard" default choice, and I think it's more
> > appropriate for a free software distribution, although I know that by
> > itself is a moderately controversial statement.
> IMHO, we generally should not do something, because any other distro is
> doing it.

No, but we can learn from others' experiences. Do you know of any
specific security problems in distributions that 

Re: [OT] Re: Open then gates

[Paul Wise]

On Sat, May 15, 2010 at 8:34 PM, Eray Aslan  wrote:

> Amen.   PKI is a naive design and for all intents and purposes will
> remain a pipe-dream.  All security relationships that is worth anything
> is bilateral and no trusted third party is willing to accept enough risk
> to warrent full trust.
>
> Using public keys for auth is a good security model and the rest of x509
> certs is just unnecessary overhead.

You might be interested in monkeysphere, which brings the PGP/GPG web
of trust to SSH and HTTPS:

http://monkeysphere.info/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktil4ip_aeaglheobhc190eu_rsmhe7z26amvd...@mail.gmail.com

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Andrei Popescu]

On Sat,15.May.10, 13:26:29, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
> > for regular users
> Would have to double check it,... but doesn't the current change also
> affect root?

By default:

# grep umask .bashrc
umask 022
#

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Julien Valroff]

Le samedi 15 mai 2010 à 13:26:29 (+0200), Christoph Anton Mitterer a écrit :
> Date: Sat, 15 May 2010 13:26:29 +0200
> From: Christoph Anton Mitterer 
> To: 581...@bugs.debian.org
> Cc: debian-devel@lists.debian.org
> Subject: Re: Bug#581729: [SQUEEZE] Document the umask change for new
>  installs
> 
> On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
> > for regular users
> Would have to double check it,... but doesn't the current change also
> affect root?

It does:

r...@gaia:~# umask
0002
r...@gaia:~# cd
r...@gaia:~# touch test
r...@gaia:~# ls -l test
-rw-rw-r-- 1 root root 0 15 mai   14:43 test

Cheers,
Julien


-- 
Julien Valroff 
http://www.kirya.net
GPG key: 4096R/290D20C5 
092F 4CB5 5F19 E006 1CFD  B489 D32B 8D66 290D 20C5


signature.asc
Description: Digital signature

[OT] Re: Open then gates

[Eray Aslan]

On 15.05.2010 08:24, Russ Allbery wrote:
> Christoph Anton Mitterer  writes:
>> And personally, I really do _not_ trust some of the CAs which are
>> included/enabled per default.
> 
> Having done business with several of them, I don't trust any commercial
> CA.  This is a way more fundamental problem.  Essentially no X.509 used on
> the Internet uses trustworthy CAs.  X.509 for web authentication is, in
> practice, not an authentication mechanism.  It's solely an encryption
> mechanism.  It's almost trivial to bypass the authentication portion if
> you're familiar with the business practices of the CAs.

Amen.   PKI is a naive design and for all intents and purposes will
remain a pipe-dream.  All security relationships that is worth anything
is bilateral and no trusted third party is willing to accept enough risk
to warrent full trust.

Using public keys for auth is a good security model and the rest of x509
certs is just unnecessary overhead.

-- 
Eray


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bee94df.6060...@caf.com.tr

Re: debian/watch problem due to http://code.google.com download page's link format change

[Asias He]

On Sat, May 15, 2010 at 5:48 PM, Osamu Aoki  wrote:
> Hi,
>
> I guess we need to generarize situation on sf.net to other popular
> download sites.  This data is used mainly by uscan program.

Yes.

> When the watch file has an URL matching with the Perl regexp
> "^http://sf\.net/";, the uscan program substitutes it with
> "http://qa.debian.org/watch/sf.php/"; and then applies this rule. The URL
> redirector service at this http://qa.debian.org/ is designed to offer a
> stable redirect service to the desired file for the watch file having
> "http://sf.net/project/tar-name-(.+)\.tar\.gz". This solves issues
> related to the periodically changing URL there.
>
> So if someone impliment similar URL redirector service, we can have
> stable link.

Can http://qa.debian.org provide this redirector service?
Whom/Which team should we contact if we need this kind of service?
Thanks.
-- 
Best Regards
Asias He


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktindiczq3schykg5m422iksq4bbr-nzdsskxd...@mail.gmail.com

Re: Open then gates

[Robert Klotzner]

On Saturday 15 May 2010 13:47:43 Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 13:22 +0200, Michael Biebl wrote:

> 
> It just shows how such stuff can completely undermine security, and one
> even haven't thought that this would possible.

This applies to any change you make to a piece of software or a  system. 
Absuluetly every change you make can open up a security hole, what is the 
solution? Stick to what we have and leave it?

There is a reason why things like selinux are developed.

In principle the concept of UPG is safe, of course there could be something 
nobody has thought of, but as the concept is already in use in other 
distributions the chance is rather small.

Though I would understand arguments of not making the change for squeeze, as 
the testing period to find Debian specific issues with the concept, is rather 
small.

Best regards,

Robert


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

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Robert Klotzner]

On Saturday 15 May 2010 13:50:50 Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
> > This paragraph should be accompanied by something like:
> >
> > Instead of adding users to other users private groups (which has issues
> > as explained above) it is recommend to create dedicated groups for these
> > users for collaboration.
> 
> Perhaps I'm completely stupid,... but why do we have UPGs then at all?
> If we suggest users not to use them!
> For those rare cases like "a user's wife/husband" which is fully
> trusted?
> 
> 
> Cheers,
> Chris.
> 
The purpose is to make a default umask of 002 possible, without security 
problems. This makes it easier to setup directories for collaboration with the 
segid bit set, as the group for newly created files will have write 
permissions, because of the umask being 002.

Best regards,

Robert


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

Re: Bug#581434: UPG and the default umask

[Andrei Popescu]

On Sat,15.May.10, 13:30:14, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 14:23 +0300, Andrei Popescu wrote:
> > Why is an own group needed for this? Can't the admin just create groups 
> > as needed where both users shall belong?
> Well but that's always possible isn't it? So one could drop the concept
> of UPGs completely...

Sure, it makes sense with a default umask of 0022 ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
> This paragraph should be accompanied by something like:
> 
> Instead of adding users to other users private groups (which has issues as 
> explained above) it is recommend to create dedicated groups for these users 
> for collaboration. 
Perhaps I'm completely stupid,... but why do we have UPGs then at all?
If we suggest users not to use them!
For those rare cases like "a user's wife/husband" which is fully
trusted?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Open then gates

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 13:22 +0200, Michael Biebl wrote:
> And why do you think this is a Debian specific problem is completely beyond 
> me.
> 
> This was an upstream bug, found by a fellow DD, and the quickly communicated 
> to
> upstream and fixed there.
> I honestly don't see how you can blame Debian here, really.
I wrote somewhere below, in my email from 2010-05-15 03:12:34, that this
was an upstream bug and not the fault of the DD (neither you nor
Martin)...

It just shows how such stuff can completely undermine security, and one
even haven't thought that this would possible.


Cheers,
Chris.





smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Holger Levsen]

Hi Andrei,

On Samstag, 15. Mai 2010, Andrei Popescu wrote:
> Suggested text:

Thanks for that!

I have one small addition...:

> This change can however create security and/or privacy issues if the
> system administrator is not aware of it and adds users to the private
> group of another user. Also, in order to prevent security issues, some
> software will detect this and refuse to operate when there are other
> members in the user's private group and relevant files have permissions
> as created with a umask of 0002.

This paragraph should be accompanied by something like:

Instead of adding users to other users private groups (which has issues as 
explained above) it is recommend to create dedicated groups for these users 
for collaboration. 



As in: not only describe how not to do it, but also how to do it.

cheers,
Holger


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

Re: Open then gates

[Bernhard R. Link]

* Christoph Anton Mitterer  [100515 13:29]:
> On Sat, 2010-05-15 at 13:22 +0200, Bernhard R. Link wrote:
> > Sorry, adding one user to the group of another is almost as stupid as
> > adding a script in /etc/cron.daily writeable by some user.
> If the user who owns the group allows it? What else should I do in your
> opinion?

add a new group, make the user admin of the group.

If the user was supposed to tell who can go in that group, the group
would have them as the admin set by default.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100515114000.ga21...@pcpool00.mathematik.uni-freiburg.de

Bug#581733: ITP: ibus-table-cangcan -- provide Cang Jie and derived tables & Cantonese and derived tables for IBus-Table on IBus framework

[Asias He]

Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: ibus-table-cangcan
  Version : ibus-table-cangcan-1.3.0.20100512
* URL : http://code.google.com/p/ibus/
* License : GPLv3
  Programming Lang: Python
  Description : provide Cang Jie and derived tables & Cantonese and derived 
tables for IBus-Table on IBus framework

  ibus-table-cangcan provide the following input method tables for 
  IBus-Table, one of input method engines on IBus framework:

  Cang Jie and derived tables
  - Cang Jie 5   - 倉頡輸入法第五代
  - Cang Jie 3   - 倉頡輸入法第三代
  - Cang Jie (big)   - 倉頡輸入法大字集
  - Smart Cang Jie 6 - 快速倉頡輸入法六代
  - Quick 5  - 速成輪入法第五代
  - Quick 3  - 速成輪入法第三代
  - Quick (classic)  - 速成輪入法古典版
  - Easy (big)   - 輕鬆輸入法大字集

  Cantonese and derived tables
  - Cantonese Pinyin - 廣東拼音輸入法
  - Canton HK- 港式廣東話輸入法
  - Jyutping - 粵語拼音輸入法



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515113359.5828.70520.report...@localhost

Re: Open then gates

[Michael Biebl]

On 15.05.2010 12:53, Christoph Anton Mitterer wrote:

> udisks should have probably not exported the dm-crypt keys to normal
> users, but it did.

And why do you think this is a Debian specific problem is completely beyond me.

This was an upstream bug, found by a fellow DD, and the quickly communicated to
upstream and fixed there.
I honestly don't see how you can blame Debian here, really.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#581732: ITP: ibus-table-xingyin -- provide structural and phonetic tables for IBus-Table on IBus framework

[Asias He]

Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: ibus-table-xingyin
  Version : ibus-table-xingyin-1.3.0.20100512
* URL : http://code.google.com/p/ibus/
* License : GPLv3
  Programming Lang: Python
  Description : provide structural and phonetic tables for IBus-Table on 
IBus framework

  ibus-table-xingyin provide structural and phonetic tables for IBus-Table 
  on IBus framework:

  Structural (Xing Ma) input methods
  - Stroke5 (筆順五碼) 
  - Wubi86 (五笔86) 
  - Xinhua (新华) 
  - Zhengma (郑码) 

  Phonetic (Yin Ma) input methods
  - Erbi and Erbi QS (二笔、二笔青松) 
  - Wu (五笔) 
  - Yong (永码) 
  - ZhuYin and ZhuYin Big (注音、注音大字集) 
  - ZiRanMa (自然码) 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515112957.5310.78045.report...@localhost

Re: Bug#581434: UPG and the default umask

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 14:23 +0300, Andrei Popescu wrote:
> Why is an own group needed for this? Can't the admin just create groups 
> as needed where both users shall belong?
Well but that's always possible isn't it? So one could drop the concept
of UPGs completely...


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Open then gates

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 13:22 +0200, Bernhard R. Link wrote:
> Sorry, adding one user to the group of another is almost as stupid as
> adding a script in /etc/cron.daily writeable by some user.
If the user who owns the group allows it? What else should I do in your
opinion?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#581729: [SQUEEZE] Document the umask change for new installs

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
> for regular users
Would have to double check it,... but doesn't the current change also
affect root?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#581434: UPG and the default umask

[Andrei Popescu]

On Sat,15.May.10, 13:03:16, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 10:04 +0200, Andreas Metzler wrote:
> > #2 UPG with umask 022 is useless.
> Why is it?
> It makes that every user has its own group, and that other users can be
> added to it.
> This alone doesn't have any effect of course, as such added users have
> read rights anyway.
> But now it's easy for the owner of files to selectively set
> write-permissions for single files.

Why is an own group needed for this? Can't the admin just create groups 
as needed where both users shall belong?

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Open then gates

[Bernhard R. Link]

* Christoph Anton Mitterer  [100515 12:53]:
> > If regular users can add other people to groups on your system, you have
> > way more serious security problems than user-private groups, and those
> > security problems are not created by Debian.
> Of course I talk about having this done by root.
> It seems you do not have experience with systems with several thousands
> of users, do you?
> If I'm e.g. a root user at my university, or an empowered registration
> authority for CERN,... I really cannot check whether what my users ask
> is sane.
> If user B says, please add user A to my group... I'll do it as long as
> no system user/group is involved.

Sorry, adding one user to the group of another is almost as stupid as
adding a script in /etc/cron.daily writeable by some user.

> > But that's your misconfiguration, not
> > something Debian did.
> Honestly,... real world is different... see my example above in big
> organisations, consider the fact that users have typically no idea what
> they doing...

Especially in large organisations all that "umask 022" is an extreme
pain. Finally having a sane default umask will help things here, though
I fear there are still enough other programs hardcoding 022 as if there
still were the 80ties of the last century...

Having a sane working configuration in which things that should work
work and things that should not work do not work is the best security.
Especially in large installations just having everything work and people
can just collaborate and write to the project directories and what
people write into project directories is project-writeable is the best
security: Remember that not-tech-savy users also do not know how to
properly give permissions. So if you lock things down more than needed,
all you get is people doing chmod 777 file, because that is what
obviously works...

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100515112202.ga21...@pcpool00.mathematik.uni-freiburg.de

Bug#581729: [SQUEEZE] Document the umask change for new installs

[Andrei Popescu]

Package: release-notes
Severity: whishlist
Tags: squeeze
X-Debbugs-CC: debian-devel@lists.debian.org

On Sat,15.May.10, 08:41:29, Christian PERRIER wrote:
 
> More generally speaking, this umask change probably deserves to be
> mentioned in the Release Notesalong with a good rationale about
> why, no, this isn't Debian giving up to years of being security-wise.

Suggested text:

---
The default 'umask' for new installs is changed
===

Starting with base-files version 5.4 the default umask for new installs 
is 0002 instead of 0022 for regular users (system users, like the ones 
used for various daemons and services are not affected).

The new umask is more useful on systems where normal users are by 
default members of an own private group, which no other user belongs to.  
Such a scheme is known as 'User Private Groups' (UPG) and has been the 
default in Debian for several releases.

This change can however create security and/or privacy issues if the 
system administrator is not aware of it and adds users to the private 
group of another user. Also, in order to prevent security issues, some 
software will detect this and refuse to operate when there are other 
members in the user's private group and relevant files have permissions 
as created with a umask of 0002.
---

Comments welcome.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Bug#581434: UPG and the default umask

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 10:04 +0200, Andreas Metzler wrote:
> #2 UPG with umask 022 is useless.
Why is it?
It makes that every user has its own group, and that other users can be
added to it.
This alone doesn't have any effect of course, as such added users have
read rights anyway.
But now it's easy for the owner of files to selectively set
write-permissions for single files.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Open then gates

[Christoph Anton Mitterer]

On Sat, 2010-05-15 at 09:04 +0200, Tollef Fog Heen wrote:
> You can make that argument for just about all the daemons that are
> shipped in the distro.
Yes :)


> Should ssh not start by default or just listen
> to localhost for instance?
Personally,... I'd prefer the listen to localhost only (per default)
solution.

But I'm aware that such behaviour is probably disliked by the majority.

Nevertheless,... when installing openssh-server,... you're already
actively deciding to do so...
But the 002 would be shipped per default...


> Me, I'd rather we stopped shipping /etc/default/* files with ENABLE=NO
> and similar silliness – if you want to disable a daemon (or it should
> not be enabled by default), put that information into the Default-Start
> LSB header or kill the S rcN.d links/make them into K links.
Well but that's just a technical issue on how to enable/disable things,
isn't it?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Open then gates

[Christoph Anton Mitterer]

On Fri, 2010-05-14 at 22:22 -0700, Russ Allbery wrote:
> These are really odd complaints to bring against Debian given that these
> are not Debian issues.  Firefox, for example, works exactly the same way
> everywhere.  What do you want Debian to do, write our own web browser?
> There are limits to what a distribution can do.
Again, these are just example where things could be secured
I do of course not want to Debian write it's own browser, but we already
patch some of them "quite heavily", don't we?
E.g. firefox to support all the plugin-packages stuff?


> For example, here, you don't appear to understand that we're talking about
> the user umask, which should not be affecting system services,
"should not"... well... I guess this  isn't a proof, is it?
We've had so many examples of things that happened although they should
not.
udisks should have probably not exported the dm-crypt keys to normal
users, but it did.
Many scripts (don't remember a concrete example now) should have
probably set a secure PATH, but they forgot to do so, and were
attackable.
sudo should have probably been secure, but it wasn't and if we would
have added normal users to sudoers (like Ubuntu does as far as I know),
"everything" would have been vulnerable.
The openssl issue should have probably just solved some valgrind errors
(wasn't that the idea of those patches?) but it lead probably to the
great disaster in cryptography in the last years...


> If regular users can add other people to groups on your system, you have
> way more serious security problems than user-private groups, and those
> security problems are not created by Debian.
Of course I talk about having this done by root.
It seems you do not have experience with systems with several thousands
of users, do you?
If I'm e.g. a root user at my university, or an empowered registration
authority for CERN,... I really cannot check whether what my users ask
is sane.
If user B says, please add user A to my group... I'll do it as long as
no system user/group is involved.

Not to talk about the fact what happens, if at one day one wants to move
away from UPGs...


> And here, you appear to have completely misunderstood the purpose of
> user-private groups in exactly the way that I tried to explain earlier.
> If there is anyone in a user-private group other than the user
> corresponding to it, you have broken user-private groups and created a
> security hole on your system.
Yes I know... (the concept of them is really not so difficult to
understand, is it?)

> But that's your misconfiguration, not
> something Debian did.
Honestly,... real world is different... see my example above in big
organisations, consider the fact that users have typically no idea what
they doing...


And even if you don't consider...
What we had now, was already kind of semi-UPGs wasn't it?
- Everybody had his private group, which others could be added to.
- But if others were added, they did not automatically have rwx-rights
on basically everything.

With a default of 022:
The owner of the file has to manually decide to make a file writeable by
the members of his UPG, right?
Isn't that much secure as the other way round?

With a default of 077:
It'd be even better, as the owner does not only have to deliberately
decide for write, but also for read rights.


> and every distribution picks something and leaves that to site policy,
> rightfully.  022 is the "standard" default choice, and I think it's more
> appropriate for a free software distribution, although I know that by
> itself is a moderately controversial statement.
IMHO, we generally should not do something, because any other distro is
doing it.
We should simply do the right.
So let me make clear, that I don't decline 002 because of "other
distributions have 022",... I decline it because I consider it to be
inherently insecure.


> I'm paranoid by profession, and I'm still in the 022 camp, so I don't
> think this is a clear-cut decision.
You meant you're in the 002 camp, didn't you?


> A umask of 002 with UPG is almost completely equivalent to a umask of 022
> without UPG.
Only if everything works perfectly right. All software and so on.
Typically not the case...


> gamin is a superior implementation of the idea of fam for several reasons,
> one of them being that it doesn't require portmap at all.  If you're
> concerned with security, I encourage you to uninstall fam and install
> gamin and then stop worrying about this.
Well I also use gamin, but I guess people should be free to choose,
and still be on a safe side.


> > You need it for nfs-common... now you say one probably want's to have it
> > then listening to all interfaces,... but I can imagine that people
> > install it just because nfs is such a common thing and they want to have
> > the manpages in place.
> That seems like a rather questionable thing to do and then complain about
> the security stance of the distribution.
Why? I typically have e.g. openssh-server install

Re: bindv6only again

[David Weinehall]

On Thu, May 13, 2010 at 06:39:46PM +0200, Tollef Fog Heen wrote:
> ]] Salvo Tomaselli 
> 
> | On Thursday 13 May 2010 17:54:04 Tollef Fog Heen wrote:
> | > Because it does not handle non-default values.  This is just like an
> | > application that didn't handle IFS or PATH being different from its
> | > default value would be buggy.
> |
> | Do you know what happens if you move /bin/mkdir to /usr/bin/mkdir?
> 
> Why is this relevant?  If you remove a POSIX-defined utility from $PATH,
> your system is no longer POSIX-compliant, not to mention a fully-working
> Debian system.

Last time I checked, /usr/bin is also part of default $PATH...

[snip]


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100515100947.ge24...@test5.acc.umu.se

Re: debian/watch problem due to http://code.google.com download page's link format change

[Osamu Aoki]

Hi,

On Sat, May 15, 2010 at 05:16:08PM +0800, Asias He wrote:
> Hi, All
> 
> Recently, code.google.com changed the download page link format.
> As a result, the old debian/watch file in packages whose upstream source code
> hosted on code.google.com did work anymore.
> 
> Take the ibus project for example:
> $ cat ibus/debian/watch
> version=3
> http://code.google.com/p/ibus/downloads/list \
> http://ibus.googlecode.com/files/ibus-([0-9].*)\.tar\.gz
> 
> The new download page contain the "detail" link, one has to follow
> the new "detail" link in order to find the real download url.
> something like this:
> http://code.google.com/p/ibus/downloads/list
> http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q=
> http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz
> 
> I believe this problem affects all the packages whose upstream source
> code is hosted on code.google.com.
> 
> Is there an easy way to deal this.

I guess we need to generarize situation on sf.net to other popular
download sites.  This data is used mainly by uscan program.

When the watch file has an URL matching with the Perl regexp
"^http://sf\.net/";, the uscan program substitutes it with
"http://qa.debian.org/watch/sf.php/"; and then applies this rule. The URL
redirector service at this http://qa.debian.org/ is designed to offer a
stable redirect service to the desired file for the watch file having
"http://sf.net/project/tar-name-(.+)\.tar\.gz". This solves issues
related to the periodically changing URL there. 

So if someone impliment similar URL redirector service, we can have
stable link.

Until then, we need to keep up each watch file manually.

Osamu


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

Re: debian/watch problem due to http://code.google.com download page's link format change

[Jakub Wilk]

* Asias He , 2010-05-15, 17:16:

Recently, code.google.com changed the download page link format.
As a result, the old debian/watch file in packages whose upstream source code
hosted on code.google.com did work anymore.

[...]

The new download page contain the "detail" link, one has to follow
the new "detail" link in order to find the real download url.
something like this:
http://code.google.com/p/ibus/downloads/list
http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q=
http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz

I believe this problem affects all the packages whose upstream source
code is hosted on code.google.com.

Is there an easy way to deal this.


Yes, there is (for some values of "easy"):
http://bugs.debian.org/581622#10

--
Jakub Wilk


signature.asc
Description: Digital signature

debian/watch problem due to http://code.google.com download page's link format change

[Asias He]

Hi, All

Recently, code.google.com changed the download page link format.
As a result, the old debian/watch file in packages whose upstream source code
hosted on code.google.com did work anymore.

Take the ibus project for example:
$ cat ibus/debian/watch
version=3
http://code.google.com/p/ibus/downloads/list \
http://ibus.googlecode.com/files/ibus-([0-9].*)\.tar\.gz

The new download page contain the "detail" link, one has to follow
the new "detail" link in order to find the real download url.
something like this:
http://code.google.com/p/ibus/downloads/list
http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q=
http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz

I believe this problem affects all the packages whose upstream source
code is hosted on code.google.com.

Is there an easy way to deal this.

Thanks.

--
Best Regards
Asias He


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikzsbarfokjp0qmx5uknwt0bxuem2gce9173...@mail.gmail.com

Re: Bug#581434: UPG and the default umask

[Andreas Metzler]

Santiago Vila  wrote:
[...]
> Problems like that are expected to happen, and I think we should be
> ready to fix them as they are found, so that the umask setting can
> really be a choice of the system admin, not an imposition of certain
> key programs who do not work well enough on systems having UPG and a
> default umask of 002.

> I remember that procmail had a similar problem, and the author
> implemented a build macro for systems having UPG. From the changelog:

> 1999/03/02: v3.12
>  Changes to procmail:
>  - Don't use $HOME/.procmailrc if it's group-writable or in a
>group-writable directory, unless it's the user's default group
>and GROUP_PER_USER is set in config.h

Hello,

afaiui we have this problem:

#1 Debian supports both UPG and non-UPG setups.
#2 UPG with umask 022 is useless.
#3 non-UPG with umask 002 is insecure.
#4 We cannot reliably detect UPG-setups. (The setting
  USERGROUPS=yes/no in /etc/adduser.conf is not relevant, e.g. in a
  NIS szenario users are generated on the master system.)

The solution applied to procmail, disabling .procmailrc permission
sanity check at compile time is not really a bugfix, but a policy
change, dropping #1 in favour of #2.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1512c7-iq3@argenau.downhill.at.eu.org

Re: Open then gates

[Robert Klotzner]

> You need to explain clearly how the umask of 0002 is insecure. If you
> have members in your user private group, then your group isn't private,
> is it? UPG is designed to NOT have anyone else in your group except you.
> So, adding the write bit on the group mode does not affect security in
> the least.
> 

Also as far as I understood from a previous post, this change will only affect 
new installations, not existing ones. So even if a user misunderstood the 
concept and added other users to his private group, this change does not affect 
him.  If the change is documented in the release notes and in the installation 
manual of squeeze, I do not see any problems.  Of course you can assume that 
the user does not read them and just does stupid things, but this is an 
entirely different issue, you can never secure a system against mindless 
administrators, no way.

So I see your argument about not to be thought of side effects, but the concept 
as such is proved already and the only harm could arise from systems where 
users assume the old umask still to be in effect when they update to squeeze 
and it will, so what is the problem?

Best regards,

Robert


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

Re: Open then gates

[Andreas Metzler]

Christian PERRIER  wrote:
> Quoting Russ Allbery (r...@debian.org):

>> >> you must not understand how user-private groups work at all

>> > Well I guess I do,...

>> Given your complaints, actually, you don't appear to.

[...]
> Is there a mail in this thread that would explain all this?
[...]

http://lists.debian.org/87fx1ykjrt@windlord.stanford.edu

cu and- I have always been wondering about the point of UPG myself
   -reas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/fmv1c7-em3@argenau.downhill.at.eu.org

Re: Open then gates

[Tollef Fog Heen]

]] Christoph Anton Mitterer 

| > Judging from the changelog of portmap, there's been a *lot* of discussion
| > and angst over this decision over the years, and it wasn't one that was
| > made easily.  I think you're overstating this a bit as an example of a bad
| > direction.
|
| Yes,.. but why "opening" something which does not need to be "open".
| If a user/admin really needs it, he'll see that something does not work,
| find out why, and then enables/opens it but _only_ if it's really
| required.

You can make that argument for just about all the daemons that are
shipped in the distro.  Should ssh not start by default or just listen
to localhost for instance? The admin will notice it's not started and
start it.  Ditto for, say, asterisk, should it only listen on loopback?

If you're installing server daemons, I don't see why you expect them to
not listen to network interfaces.  If you're uncomfortable with that,
drop an iptables rule on all your systems that sets a default policy of
DROP for incoming and outgoing traffic and just whitelist what you care
about.  Anything that's so buggy that it because of security needs to
listen to loopback only by default is IMO so buggy we shouldn't ship it
at all.

Me, I'd rather we stopped shipping /etc/default/* files with ENABLE=NO
and similar silliness – if you want to disable a daemon (or it should
not be enabled by default), put that information into the Default-Start
LSB header or kill the S rcN.d links/make them into K links.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vdap7ij7@qurzaw.linpro.no