Re: security policy / root passwords

[Michael Banck]

On Sun, Jun 09, 2013 at 07:20:16PM +0200, Michael Banck wrote:
> > Is there any policy within Debian about such matters, particularly for
> > packages that are a default part of the distribution?  Is it too late to
> > remove this popup from wheezy?
> 
> I think the best approach would be sudo and requesting the user for
> their own password - and probably be more informative about why the
> password is needed or what is being installed.

By the way, this seems to be the case for my wheezy installation,
however, I am running vanilla Gnome3, not Classic (and have been running
wheezy all along sind late 2012).

So maybe either you are missing some sudo-related package, or the
classic mode is behaving differently, possibly due to less testing (if
the sudo route is indeed the intended one).


Michael


-- 
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/20130610072118.gc26...@nighthawk.chemicalconnection.dyndns.org

Re: How should we do for font-adobe-copyrighted-fragment error?

[Atsuhito Kohda]

On Fri, 7 Jun 2013 17:07:09 +0200, Bastien ROUCARIES wrote:

> Le 7 juin 2013 09:28, "Atsuhito Kohda"  a
> écrit :
>>
>> Yes, but it looks to me there is not practical information.
> 
> Did you see the wiki?

Sorry for late reply.
If you mean
http://lintian.debian.org/tags/font-adobe-copyrighted-fragment.html
I've seen it before but it seems, at present, I can't access it.

Antway I will read information more carefully later.
Thanks for your explanation.

Best regards,   2013-6-10(Mon)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


--
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/20130610.162922.1206807919710043952.atsuhito@at-SVT

Re: security policy / root passwords

[Timo Juhani Lindfors]

Michael Banck  writes:
>> I think the best approach would be sudo and requesting the user for
>> their own password - and probably be more informative about why the
>> password is needed or what is being installed.
>
> By the way, this seems to be the case for my wheezy installation,
> however, I am running vanilla Gnome3, not Classic (and have been running
> wheezy all along sind late 2012).

Perhaps your user is in the sudo group? If yes then at least in squeeze
policykit will consider you to be admin:

$ cat /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf
[Configuration]
AdminIdentities=unix-group:sudo


-- 
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/848v2izak6@sauna.l.org

Re: How should we do for font-adobe-copyrighted-fragment error?

[Niels Thykier]

On 2013-06-10 09:29, Atsuhito Kohda wrote:
> On Fri, 7 Jun 2013 17:07:09 +0200, Bastien ROUCARIES wrote:
> 
>> Le 7 juin 2013 09:28, "Atsuhito Kohda"  a
>> écrit :
>>>
>>> Yes, but it looks to me there is not practical information.
>>
>> Did you see the wiki?
> 
> Sorry for late reply.
> If you mean
> http://lintian.debian.org/tags/font-adobe-copyrighted-fragment.html
> I've seen it before but it seems, at present, I can't access it.
> 
> Antway I will read information more carefully later.
> Thanks for your explanation.
> 
> Best regards, 2013-6-10(Mon)
> 

The "wiki" would probably be [1].

As for lintian.d.o being 404 atm.  We had a technical (software-only)
problem.  The site should be back to normal in a couple of days once
lintian has had time to process the entire archive.

~Niels

[1] http://wiki.debian.org/qa.debian.org/type1nondfsg



-- 
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/51b581e7.8030...@thykier.net

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Wouter Verhelst]

On 08-06-13 00:33, Manuel A. Fernandez Montecelo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian SDL packages maintainers 
> 
> 
> * Package name: libsdl2-mixer
>   Version : 2.0.0~rc1
>   Upstream Author : Sam Lantinga 
> * URL : http://www.libsdl.org/tmp/SDL_mixer/
> * License : zlib/linpng
>   Programming Lang: C
>   Description : Mixer library for SDL2
> 
>  SDL_mixer is a sample multi-channel audio mixer library.  It supports any
>  number of simultaneously playing channels of 16 bit stereo audio, plus a 
> single
>  channel of music, mixed by the popular FLAC, MikMod MOD, Timidity MIDI, Ogg
>  Vorbis, and SMPEG MP3 libraries.

Isn't this packaged already? You don't need to file WNPP bugs for SONAME
bumps...

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51b5875a.3000...@debian.org

Re: How should we do for font-adobe-copyrighted-fragment error?

[Atsuhito Kohda]

Hi Niels,

On Mon, 10 Jun 2013 09:36:07 +0200, Niels Thykier wrote:

> The "wiki" would probably be [1].

Ah, I remembered I've seen it.  I forgot to write down its URL.
(But there were long long list of packages in the bottom 
when I saw it if I remebered it correctly.)

> As for lintian.d.o being 404 atm.  We had a technical (software-only)
> problem.  The site should be back to normal in a couple of days once
> lintian has had time to process the entire archive.

Okay thanks for your help.
Best regards,   2013-6-10(Mon)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


-- 
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/20130610.170634.801690527194151333.atsuhito@at-SVT

Re: security policy / root passwords

[Alexey Serikov]

A few points:

1) if your user is part of sudo group, most of the time gnome will ask for
your user's password instead of root's.
2) Debian is a finite set of software. It provides packages (literally
thousands of them) that are stable, safe and malicious pop-ups free. It
also provides packages enabling user to run software that cannot be found
in Debian's pool (and is potentially unsafe) in a safe, virtualized
environment (qemu and stuff).
3) xfce needs less root
4) asking a user to open up a console and type their root's password there
will add unnecessary complexity while enforcing a security mechanism like
selinux will be a pain. Please leave it be.


On Mon, Jun 10, 2013 at 9:31 AM, Timo Juhani Lindfors
wrote:

> Michael Banck  writes:
> >> I think the best approach would be sudo and requesting the user for
> >> their own password - and probably be more informative about why the
> >> password is needed or what is being installed.
> >
> > By the way, this seems to be the case for my wheezy installation,
> > however, I am running vanilla Gnome3, not Classic (and have been running
> > wheezy all along sind late 2012).
>
> Perhaps your user is in the sudo group? If yes then at least in squeeze
> policykit will consider you to be admin:
>
> $ cat /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf
> [Configuration]
> AdminIdentities=unix-group:sudo
>
>
> --
> 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/848v2izak6@sauna.l.org
>
>

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Adam Borowski]

On Mon, Jun 10, 2013 at 09:59:22AM +0200, Wouter Verhelst wrote:
> On 08-06-13 00:33, Manuel A. Fernandez Montecelo wrote:
> > * Package name: libsdl2-mixer
> 
> Isn't this packaged already? You don't need to file WNPP bugs for SONAME
> bumps...

It's a massive new major release.  Think perl5 vs perl6.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130610083242.ga17...@angband.pl

Re: Survey answers part 1: systemd has too many dependencies, …

[Ondřej Surý]

On Sun, Jun 9, 2013 at 2:46 PM, Vincent Bernat  wrote:

>  ❦  9 juin 2013 11:45 CEST, Bjørn Mork  :
>
> > You do of course not have to agree.  This is my personal opinion only.
> > But I believe it is useful to read Jamie Zawinski's view on screensavers
> > and toolkit library dependencies, and try to figure out how that can be
> > relevant to systemd and external dependencies:
> > http://www.jwz.org/xscreensaver/toolkits.html
>
> systemd does not rely on a toolkit. So, most of the arguments listed by
> Jamie do not hold. I suppose that you are mostly worried by libdbus
> since other libraries are already used in other critical
> daemons.


Personally I would be more worried about libpam and it's ability to load
random pam modules into a memory, and we have a plenty of them.

$ apt-cache search "^libpam-" | wc -l
61

Do you have idea how would a buggy PAM module affect PID 1?

O.
-- 
Ondřej Surý 

Re: X.509 and CA certificates for other purposes (i.e. the IGTF)

[Josselin Mouette]

Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit : 
> Maybe crypto consolidation arround libnss will greatly help here.
> jessie release goal ?

If we consolidate on a crypto library, it would be good for it to use
ca-certificates and not a pre-compiled list of certificates.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1370855048.3721.245.camel@pi0307572

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Wouter Verhelst]

On 10-06-13 10:32, Adam Borowski wrote:
> On Mon, Jun 10, 2013 at 09:59:22AM +0200, Wouter Verhelst wrote:
>> On 08-06-13 00:33, Manuel A. Fernandez Montecelo wrote:
>>> * Package name: libsdl2-mixer
>>
>> Isn't this packaged already? You don't need to file WNPP bugs for SONAME
>> bumps...
> 
> It's a massive new major release.  Think perl5 vs perl6.

The point isn't that "it's in the archive", the point is that "you don't
need to deal with WNPP for new upstream versions of stuff you're already
doing".

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51b59710.2050...@debian.org

Re: security policy / root passwords

[Josselin Mouette]

Hi,

Le dimanche 09 juin 2013 à 18:45 +0200, Daniel Pocock a écrit : 
> There have been multiple complaints about the new Gnome popup asking for
> the root password
> 
> I opened a bug for discussion about the issue, but it was closed by
> another DD (not the maintainer) - [1].  Other users have come across the
> bug too and requested attention for it with the same concerns that I have.
> 
> Essentially, my feeling is that users should be encouraged to NEVER put
> their root password into some popup that appears spontaneously on their
> computer.  Having this popup in Debian, by default, desensitizes users
> to the type of popups that will aim to deceive them.

I think there is some big confusion here.

It is not new for GNOME to ask for the root password for actions that
require root permissions. This is done through PolicyKit, which avoids
to run privileged code in the GUI, but which will nevertheless require
to type the root password in an unprivileged process (there is not much
way around that).

What is new is that PackageKit asks for a system update *systematically*
when it finds the system is not up-to-date. I don’t know why, but it
seems to have started with the wheezy release, it did not happen during
the freeze.

I consider it a bug, and one that we should aim to fix in the first
wheezy point release.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1370855422.3721.249.camel@pi0307572

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Chow Loong Jin]

On Mon, Jun 10, 2013 at 11:06:24AM +0200, Wouter Verhelst wrote:
> On 10-06-13 10:32, Adam Borowski wrote:
> > On Mon, Jun 10, 2013 at 09:59:22AM +0200, Wouter Verhelst wrote:
> >> On 08-06-13 00:33, Manuel A. Fernandez Montecelo wrote:
> >>> * Package name: libsdl2-mixer
> >>
> >> Isn't this packaged already? You don't need to file WNPP bugs for SONAME
> >> bumps...
> > 
> > It's a massive new major release.  Think perl5 vs perl6.
> 
> The point isn't that "it's in the archive", the point is that "you don't
> need to deal with WNPP for new upstream versions of stuff you're already
> doing".

I think it was more of "it's going to be a new source package."

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: How to bump the SONAME of a library ? [WAS: DH way to set SONAME]

[Ondřej Surý]

http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html


On Mon, Jun 10, 2013 at 1:04 AM, Jerome BENOIT wrote:

> Hello List,
>
> I am not so sure what I must understand by `bump the SONAME':
> given that libtool machinery is employed, does is mean that
> `current' must be increased by one ?
>
> Thanks in advance,
> Jerome
>
>
> --
> 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/51b509e7.90...@rezozer.net
>
>


-- 
Ondřej Surý 

Re: How to bump the SONAME of a library ? [WAS: DH way to set SONAME]

[Emilio Pozuelo Monfort]

On 10/06/13 01:04, Jerome BENOIT wrote:
> Hello List,
> 
> I am not so sure what I must understand by `bump the SONAME':
> given that libtool machinery is employed, does is mean that
> `current' must be increased by one ?

You really should read [1] if you're maintaining shared libraries in Debian
(it's a bit outdated but most things are still relevant). [2] is also a good
read, specially if you're doing upstream development, patching the library or
bumping the SONAME. The libtool manual (that Ondřej linked) is also relevant
given your upstream is using libtool.

Emilio

[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[2] http://www.akkadia.org/drepper/dsohowto.pdf


-- 
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/51b59f38.8090...@debian.org

Re: X.509 and CA certificates for other purposes (i.e. the IGTF)

[Bastien ROUCARIES]

On Mon, Jun 10, 2013 at 11:04 AM, Josselin Mouette  wrote:
> Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit :
>> Maybe crypto consolidation arround libnss will greatly help here.
>> jessie release goal ?
>
> If we consolidate on a crypto library, it would be good for it to use
> ca-certificates and not a pre-compiled list of certificates.

See  #704180 and we could share trust between gnome and mozilla (NSS)

> --
>  .''`.  Josselin Mouette
> : :' :
> `. `'
>   `-
>
>
> --
> 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/1370855048.3721.245.camel@pi0307572
>


--
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/cae2spazuchzatxku0phx8w6jnbh5x6fuxfccgnnojrbrbn7...@mail.gmail.com

Re: X.509 and CA certificates for other purposes (i.e. the IGTF)

[Josselin Mouette]

Le lundi 10 juin 2013 à 11:47 +0200, Bastien ROUCARIES a écrit : 
> On Mon, Jun 10, 2013 at 11:04 AM, Josselin Mouette  wrote:
> > Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit :
> >> Maybe crypto consolidation arround libnss will greatly help here.
> >> jessie release goal ?
> >
> > If we consolidate on a crypto library, it would be good for it to use
> > ca-certificates and not a pre-compiled list of certificates.
> 
> See  #704180 and we could share trust between gnome and mozilla (NSS)

It looks like we can fix this long-standing issue. Thanks for the
pointer!

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1370859292.3721.256.camel@pi0307572

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Jonathan Dowland]

We'll need binaries for sdl 1 and 2 coexisting from two different source 
packages I believe.

--
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/0d0aca7b-918f-4ba1-80e1-f1f54c8df...@debian.org

Re: Survey answers part 1: systemd has too many dependencies, …

[Vincent Bernat]

Le 2013-06-10 10:18, Ondřej Surý a écrit :


systemd does not rely on a toolkit. So, most of the arguments
listed by
Jamie do not hold. I suppose that you are mostly worried by libdbus
since other libraries are already used in other critical
daemons.


Personally I would be more worried about libpam and it's ability to
load random pam modules into a memory, and we have a plenty of them.

$ apt-cache search "^libpam-" | wc -l
61

Do you have idea how would a buggy PAM module affect PID 1?


No PAM module is executed in PID 1. All PAM code is executed after 
forking a child process and only for jobs requiring PAM explicitly.



--
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/d3c9d21655f1100453e9bc528d4c0...@luffy.cx

Bug severity and private data disclosure

[Vincent Lefevre]

I reported a bug involving private data disclosure, more precisely,
on some network, when printing a file with CUPS 1.6, the file is
printed on a wrong printer[*]. The bug severity was downgraded to
important (i.e. non-RC), despite the obvious security problem. The
given reason was that this kind of security problem is not mentioned
on:

  http://www.debian.org/Bugs/Developer.en.html#severities

If Debian really minds about some forms of security bugs such as
private data disclosure, something should be done... Perhaps replace

  allowing access to the accounts of users who use the package

by

  allowing access to private data of users who use the package

(BTW, logging passwords in general log files would fall in the same
class of security bugs.)

[*] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711848

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130610111552.ga17...@ypig.lip.ens-lyon.fr

Re: security policy / root passwords

[Daniel Pocock]

On 10/06/13 10:21, Alexey Serikov wrote:
> A few points:
>
> 1) if your user is part of sudo group, most of the time gnome will ask
> for your user's password instead of root's.
> 2) Debian is a finite set of software. It provides packages (literally
> thousands of them) that are stable, safe and malicious pop-ups free.
> It also provides packages enabling user to run software that cannot be
> found in Debian's pool (and is potentially unsafe) in a safe,
> virtualized environment (qemu and stuff).

The potential phishing attack would be likely to take one of two forms:

a) a web site displaying a "PolicyKit" popup that resembles the wording
of the Debian popup

b) an X window compromise that allows an attacker to display a popup
(although such compromises often give the attacker the ability to
monitor keystrokes and obtain passwords in other ways)

There is no suggestion that any existing package contains a malicious popup.

> 3) xfce needs less root
> 4) asking a user to open up a console and type their root's password
> there will add unnecessary complexity while enforcing a security
> mechanism like selinux will be a pain. Please leave it be.
>

pain means the user thinks about what they are doing and follows a
pre-defined procedure that is known to be relatively secure

The real issue here is not about the technical quality of the popup or
whether the package "works" or not, it is about the potential for this
type of workflow to condition users into a mindset of trusting popups
that makes a percentage of users more likely to be caught by a phishing
attack.



-- 
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/51b5b9b9.4080...@pocock.com.au

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Andrey Rahmatullin]

On Mon, Jun 10, 2013 at 05:12:22PM +0800, Chow Loong Jin wrote:
> > >>> * Package name: libsdl2-mixer
> > >>
> > >> Isn't this packaged already? You don't need to file WNPP bugs for SONAME
> > >> bumps...
> > > 
> > > It's a massive new major release.  Think perl5 vs perl6.
> > 
> > The point isn't that "it's in the archive", the point is that "you don't
> > need to deal with WNPP for new upstream versions of stuff you're already
> > doing".
> 
> I think it was more of "it's going to be a new source package."
Which is countered by "you don't need an ITP lock for stuff already having
a maintainer".

-- 
WBR, wRAR


--
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/20130610114255.ga2...@belkar.wrar.name

Re: security policy / root passwords

[Simon McVittie]

On 10/06/13 12:34, Daniel Pocock wrote:
> a) a web site displaying a "PolicyKit" popup that resembles the wording
> of the Debian popup

GNOME Shell does mitigate this by using a distinctive UI for
"system-modal dialogs", which makes use of the fact that the Shell is
the window compositor in order to dim the rest of the screen:



That's the "power off" dialog, but PolicyKit prompts are similar. Notice
that everything outside the dialog is desaturated and darker than usual.
I would hope that web browsers don't have that level of control over the
system's appearance (going to full-screen is the closest they could get,
and they'd still have to reproduce a darkened form of the entire screen
contents somehow).

> b) an X window compromise that allows an attacker to display a popup
> (although such compromises often give the attacker the ability to
> monitor keystrokes and obtain passwords in other ways)

I don't know whether a client with X access would be able to emulate a
system-modal dialog more closely; it might be able to do tricks with
screenshots? As you say, input logging is probably more of a concern here.

S


-- 
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/51b5c2ca.70...@debian.org

About Re-Distribution

[Shivam Pandya]

Hello sir/ Ma'm

I'm Shivam Pandya, and study in my last year, I want to develop a OS in my
final year project, I found debian from wiki, Can you help me out from
this. can you please guide me that how could I develop (re distribute) my
own one, what steps needed if I use Windows.?


-- 
*Thanks & Regards *
- Shivam Pandya

Re: How to bump the SONAME of a library ? [WAS: DH way to set SONAME]

[Raúl Benencia]

On Mon, Jun 10, 2013 at 11:41:12AM +0200, Emilio Pozuelo Monfort wrote:
> You really should read [1] if you're maintaining shared libraries in Debian
> (it's a bit outdated but most things are still relevant). [2] is also a good
> read, specially if you're doing upstream development, patching the library or
> bumping the SONAME. The libtool manual (that Ondřej linked) is also relevant
> given your upstream is using libtool.
> 
> Emilio
> 
> [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> [2] http://www.akkadia.org/drepper/dsohowto.pdf

Debian Policy[0] have also some must-read documentation about shared
libraries.

[0] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

Cheers,
--
Raúl Benencia


signature.asc
Description: Digital signature

Re: security policy / root passwords

[Daniel Pocock]

On 10/06/13 14:12, Simon McVittie wrote:
> On 10/06/13 12:34, Daniel Pocock wrote:
>> a) a web site displaying a "PolicyKit" popup that resembles the wording
>> of the Debian popup
> GNOME Shell does mitigate this by using a distinctive UI for
> "system-modal dialogs", which makes use of the fact that the Shell is
> the window compositor in order to dim the rest of the screen:
>
> 
>
> That's the "power off" dialog, but PolicyKit prompts are similar. Notice
> that everything outside the dialog is desaturated and darker than usual.
> I would hope that web browsers don't have that level of control over the
> system's appearance (going to full-screen is the closest they could get,
> and they'd still have to reproduce a darkened form of the entire screen
> contents somehow).


That screenshot appears to be Gnome 3.  I log in with Gnome Classic so
maybe I'm experiencing something different.

The dialog I see does not have the appearance of the screenshot in that
link - you can see a screenshot attached to the bug here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=708548.png;att=1;bug=708548

and it is not modal either.  Those may be other bugs in the way this works.

I agree that having a modal dialog with a dimmed background would help,
maybe this is meant to happen but the code is not working correctly in
Gnome classic mode?

It was also demonstrated with Windows 7 that users could be tricked by
web sites that simply dimmed the background of the browser window - so
it is not a perfect solution and I would personally prefer to see users
referred to initiate "su" or "sudo" on their own.

Another way to do this might be telling them about updates at login time
or when the screen is locked.  Those are places where the user normally
enters a password anyway.  Immediately after they enter the password,
the user could be informed about pending updates, within the same login
UI, rather than having popups appearing out of nowhere.



-- 
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/51b5cc89.3060...@pocock.com.au

Re: security policy / root passwords

[Uoti Urpala]

Daniel Pocock wrote:
> It was also demonstrated with Windows 7 that users could be tricked by
> web sites that simply dimmed the background of the browser window - so
> it is not a perfect solution and I would personally prefer to see users
> referred to initiate "su" or "sudo" on their own.

Initiate "su" or "sudo" as in from a terminal? Conditioning users to
write commands in a terminal when prompted by a dialog sounds even worse
than leaking passwords. At least leaking system passwords is less
catastrophic when the system allows no remote login.



-- 
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/1370869938.18948.18.camel@glyph.nonexistent.invalid

Re: Bug severity and private data disclosure

[Bastien ROUCARIES]

On Mon, Jun 10, 2013 at 1:15 PM, Vincent Lefevre  wrote:
> I reported a bug involving private data disclosure, more precisely,
> on some network, when printing a file with CUPS 1.6, the file is
> printed on a wrong printer[*]. The bug severity was downgraded to
> important (i.e. non-RC), despite the obvious security problem. The
> given reason was that this kind of security problem is not mentioned
> on:
>
>   http://www.debian.org/Bugs/Developer.en.html#severities
>
> If Debian really minds about some forms of security bugs such as
> private data disclosure, something should be done... Perhaps replace
>
>   allowing access to the accounts of users who use the package
>
> by
>
>   allowing access to private data of users who use the package
>
> (BTW, logging passwords in general log files would fall in the same
> class of security bugs.)
>
> [*] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711848
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>


Hi,

hplip is affected by the same kind of bug see #653062. I am a teacher
and instead of printing on the correct printer it print the subject of
my test on the student network printer*

Bastien

* i have the same short name of the printer of the student and staff
network only the FQDN change...

> --
> 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/20130610111552.ga17...@ypig.lip.ens-lyon.fr
>


--
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/cae2spazxbu6dikxykp0r0igc5rpgjfftv+dyvswmzzlmluv...@mail.gmail.com

Re: security policy / root passwords

[Simon McVittie]

On 10/06/13 13:54, Daniel Pocock wrote:
> That screenshot appears to be Gnome 3.  I log in with Gnome Classic so
> maybe I'm experiencing something different.

I did say "GNOME Shell". The "fallback" GNOME 3.4 session (which might
well be called "Classic" in the UI in wheezy) doesn't use Shell, so it
doesn't have access to the same way to mitigate this, and I would expect
it to use the standalone PolicyKit UI, which is just a normal user-level
application and looks like your screenshot.

GNOME >= 3.8 has a new "Classic" mode which uses Shell, but adjusts it
to look and behave more like GNOME 2. I don't know how its PolicyKit
dialogs behave - they're probably GNOME Shell modal dialogs in a more
GNOME-2-like (i.e. grey) colour scheme.

> I agree that having a modal dialog with a dimmed background would help,
> maybe this is meant to happen but the code is not working correctly in
> Gnome classic mode?

Fallback mode is/was a fallback for unsupported graphics hardware; it
doesn't have the UI that upstream intended, only an approximation. The
Shell-based session is "how it's meant to work".

> It was also demonstrated with Windows 7 that users could be tricked by
> web sites that simply dimmed the background of the browser window - so
> it is not a perfect solution and I would personally prefer to see users
> referred to initiate "su" or "sudo" on their own.

Sure, it's a mitigation, not a solution.

I don't think telling non-technical users they need to run cryptic
commands is desirable (they'll just not update at all!) and there are
technical limitations in su/sudo/gksu that are solved by PolicyKit[1],
but I agree that anything that asks for the user or root password should
be a response to user action.

In squeeze, the GNOME update notifier consisted of an icon in the
notification area which appeared when there were updates; when users
clicked on it, they were prompted for their password and could then
install the updates. That seems fine to me.

> Another way to do this might be telling them about updates at login time
> or when the screen is locked.  Those are places where the user normally
> enters a password anyway.  Immediately after they enter the password,
> the user could be informed about pending updates, within the same login
> UI, rather than having popups appearing out of nowhere.

That's an interesting idea; please suggest it upstream.

S

[1] among others:
* sanitizing the environment (done by sudo and PK but not by su)
* configurable level of authentication required
  (done at an abstract level by PK, done at a command-line
  level by sudo, not done at all by su)
* splitting privileged actions into an unprivileged GUI and a
  privileged daemon, rather than running the GUI with privileges
  (supported and encouraged by PK, not well-supported by sudo or su)
* ability to use system-modal prompting or a secure input path
  (partially done by PK under GNOME Shell, likely to get better
  under Wayland, not supported by sudo or su)


-- 
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/51b5d6cb.5080...@debian.org

Re: Bug severity and private data disclosure

[Jonathan Dowland]

It's amazing how much simpler Debian life becomes if one simply ignores
bug severities entirely. Of course harder to do nearer to release, but
we live in a time of relative luxury right now…


-- 
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/20130610140505.GB30122@debian

Re: Bug severity and private data disclosure

[Andrey Rahmatullin]

On Mon, Jun 10, 2013 at 03:05:05PM +0100, Jonathan Dowland wrote:
> It's amazing how much simpler Debian life becomes if one simply ignores
> bug severities entirely. 
Life for the maintainer or for the user?

-- 
WBR, wRAR


--
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/20130610141022.gb13...@belkar.wrar.name

Re: Bug severity and private data disclosure

[Ian Jackson]

(I have CC'd cups-client@packages.)

Vincent Lefevre writes ("Bug severity and private data disclosure"):
> I reported a bug involving private data disclosure, more precisely,
> on some network, when printing a file with CUPS 1.6, the file is
> printed on a wrong printer[*]. The bug severity was downgraded to
> important (i.e. non-RC), despite the obvious security problem. The
> given reason was that this kind of security problem is not mentioned
> on:

I agree with you that that bug is a potential security vulnerability.
I think the maintainer adopted an overly-close and legalistic reading
of the bug severity guidelines.  On the other hand I think the
maintainer makes good points about the lack of widespread impact.

I'm not sure exactly what consequences you think should have flowed
from the bug's RC severity.  Do you think the release should have been
delayed ?  CUPS removed from wheezy ?  Presumably not.  So it should
have been RC-ignored for wheezy.

So I agree with the main thrust of the maintainer's comments, that
this bug severity discussion is a side issue which risks distracting
us from fixing the bug.

If what you're trying to do is improve the wording of the bug severity
guidelines, have you considered emailing owner@bugs ?

Ian.


-- 
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/20917.56974.70680.161...@chiark.greenend.org.uk

Re: security policy / root passwords

[Ian Jackson]

Simon McVittie writes ("Re: security policy / root passwords"):
> * splitting privileged actions into an unprivileged GUI and a
>   privileged daemon, rather than running the GUI with privileges
>   (supported and encouraged by PK, not well-supported by sudo or su)

This gives me another opportunity to plug userv.  userv is a tool for
helping split a local program or service into differently-privileged
parts.  Specifically it's a way of letting one user execute programs
to be run as another user, with appropriate security properties.

Ian.


-- 
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/20917.57113.942820.667...@chiark.greenend.org.uk

Re: Bug severity and private data disclosure

[Vincent Lefevre]

On 2013-06-10 15:05:05 +0100, Jonathan Dowland wrote:
> It's amazing how much simpler Debian life becomes if one simply ignores
> bug severities entirely. Of course harder to do nearer to release, but
> we live in a time of relative luxury right now…

This is important for apt-listbugs, which takes into account RC bugs by
default (and asking it to list *all* important bugs is not a solution).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130610141527.gb17...@ypig.lip.ens-lyon.fr

Re: Bug severity and private data disclosure

[Vincent Lefevre]

On 2013-06-10 15:11:26 +0100, Ian Jackson wrote:
> I agree with you that that bug is a potential security vulnerability.
> I think the maintainer adopted an overly-close and legalistic reading
> of the bug severity guidelines.  On the other hand I think the
> maintainer makes good points about the lack of widespread impact.

I think that most security bugs do not have widespread impact.

> I'm not sure exactly what consequences you think should have flowed
> from the bug's RC severity.  Do you think the release should have been
> delayed ?  CUPS removed from wheezy ?  Presumably not.  So it should
> have been RC-ignored for wheezy.

This is for sid only. Having a RC severity allows one to make other
users aware of the bug via apt-listbugs. Then they can ignore it or
not... It also prevents the bug from entering testing, which is safer
for the corresponding users.

Note that this is a regression. Using the testing version (= stable
currently) is fine w.r.t. this bug.

> So I agree with the main thrust of the maintainer's comments, that
> this bug severity discussion is a side issue which risks distracting
> us from fixing the bug.
> 
> If what you're trying to do is improve the wording of the bug severity
> guidelines, have you considered emailing owner@bugs ?

Not yet.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130610142241.gc17...@ypig.lip.ens-lyon.fr

Re: security policy / root passwords

[Timo Juhani Lindfors]

Simon McVittie  writes:
> * ability to use system-modal prompting or a secure input path
>   (partially done by PK under GNOME Shell, likely to get better
>   under Wayland, not supported by sudo or su)

Not relevant to the current discussion but this got me curious: can the
input path really be secure under X11?


-- 
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/8461xmt4ly@sauna.l.org

Re: Bug severity and private data disclosure

[Didier 'OdyX' Raboud]

Hi Ian,

Le lundi, 10 juin 2013 16.11:26, Ian Jackson a écrit :
> (I have CC'd cups-client@packages.)

(I'd prefer the discussion to happen on the bug.)

> I'm not sure exactly what consequences you think should have flowed
> from the bug's RC severity.  Do you think the release should have been
> delayed ?  CUPS removed from wheezy ?  Presumably not.  So it should
> have been RC-ignored for wheezy.

Note that this bug doesn't impact wheezy and never has, according to the 
initial bugreport: "CUPS 1.5.x didn't have such a problem." We're talking 
about a bug in a new CUPS upstream release that landed in unstable recently.

> So I agree with the main thrust of the maintainer's comments, that
> this bug severity discussion is a side issue which risks distracting
> us from fixing the bug.

Let me remind how the "us" is currently defined by pointing at the cups RFH: 
#532097, any helping hand would be welcome on the cups front.

--
OdyX


--
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/201306101638.19152.o...@debian.org

Re: security policy / root passwords

[Simon McVittie]

On 10/06/13 15:36, Timo Juhani Lindfors wrote:
> Simon McVittie  writes:
>> * ability to use system-modal prompting or a secure input path
>>   (partially done by PK under GNOME Shell, likely to get better
>>   under Wayland, not supported by sudo or su)
> 
> Not relevant to the current discussion but this got me curious: can the
> input path really be secure under X11?

It can at least be a bit more robust against accidentally typing your
password into the wrong window (although perhaps not secure against
deliberate abuse by a malicious application) by taking an input grab,
like the various pinentry-* and ssh-askpass implementations do.

I'm not sure how far GNOME Shell goes with securing input to
system-modal dialogs, but again, the fact that it's modal makes it a bit
more robust against mistakes.

S


-- 
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/51b5e7f3.2000...@debian.org

Bug#711870: ITP: fonts-sarai -- TrueType fonts for Devanagari script

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: fonts-sarai
  Version : 1.0
  Upstream Author : IndLinux Team
* URL : 
http://indlinux.svn.sourceforge.net/viewvc/indlinux/trunk/fonts/sarai/
* License : GPL-2
  Programming Lang: font
  Description : TrueType fonts for Devanagari script

This font is used for Devangari script which is used by multiple Indian
languages like Sanskrit, Hindi, Marathi etc. This font was previously
part of fonts-deva-extra and since it got a new upstream moved into its
own package.

-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Re: Bug severity and private data disclosure

[Cyril Brulebois]

Vincent Lefevre  (10/06/2013):
> I reported a bug involving private data disclosure, more precisely,
> on some network, when printing a file with CUPS 1.6, the file is
> printed on a wrong printer[*]. The bug severity was downgraded to
> important (i.e. non-RC), despite the obvious security problem.

Just in case this isn't obvious: we have tags, and we have severities.
The bug is tagged security, fine; that doesn't imply it has to be RC
in addition.

Since you seem concerned about apt-listbugs, make it support listing
security bugs (optionally with a given severity threshold, so as to
ignore minor or normal bug reports tagged security), and there you go.

[ From a quick look at the changelog, it used to be supported, the
  support broke, and got removed. Fixing/adding it back might make
  sense. ]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Chow Loong Jin]

On Mon, Jun 10, 2013 at 05:42:55PM +0600, Andrey Rahmatullin wrote:
> On Mon, Jun 10, 2013 at 05:12:22PM +0800, Chow Loong Jin wrote:
> > > >>> * Package name: libsdl2-mixer
> > > >>
> > > >> Isn't this packaged already? You don't need to file WNPP bugs for 
> > > >> SONAME
> > > >> bumps...
> > > > 
> > > > It's a massive new major release.  Think perl5 vs perl6.
> > > 
> > > The point isn't that "it's in the archive", the point is that "you don't
> > > need to deal with WNPP for new upstream versions of stuff you're already
> > > doing".
> > 
> > I think it was more of "it's going to be a new source package."
> Which is countered by "you don't need an ITP lock for stuff already having
> a maintainer".

But the new source package doesn't have a maintainer until you upload it.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: Bug severity and private data disclosure

[Vincent Lefevre]

On 2013-06-10 17:16:12 +0200, Cyril Brulebois wrote:
> Since you seem concerned about apt-listbugs, make it support listing
> security bugs (optionally with a given severity threshold, so as to
> ignore minor or normal bug reports tagged security), and there you go.
> 
> [ From a quick look at the changelog, it used to be supported, the
>   support broke, and got removed. Fixing/adding it back might make
>   sense. ]

I've just reported a wishlist bug for filtering on severity/tag
combinations:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711874

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/2013061016.ga30...@xvii.vinc17.org

Re: Survey answers part 1: systemd has too many dependencies, …

[Ondřej Surý]

On Mon, Jun 10, 2013 at 12:22 PM, Vincent Bernat  wrote:

> Le 2013-06-10 10:18, Ondřej Surý a écrit :
>
>
>  systemd does not rely on a toolkit. So, most of the arguments
>>> listed by
>>> Jamie do not hold. I suppose that you are mostly worried by libdbus
>>> since other libraries are already used in other critical
>>> daemons.
>>>
>>
>> Personally I would be more worried about libpam and it's ability to
>> load random pam modules into a memory, and we have a plenty of them.
>>
>> $ apt-cache search "^libpam-" | wc -l
>> 61
>>
>> Do you have idea how would a buggy PAM module affect PID 1?
>>
>
> No PAM module is executed in PID 1. All PAM code is executed after forking
> a child process and only for jobs requiring PAM explicitly.


The document with library dependencies at
http://people.debian.org/~stapelberg/docs/systemd-dependencies.html kind of
misses this information. It might be good to add this kind of information
to that document.

Ondrej
-- 
Ondřej Surý 

Re: boot ordering and resolvconf

[Ian Jackson]

Helmut Grohne writes ("boot ordering and resolvconf"):
> Why is this assumption problematic?
> 
> A number of DNS caches (dnsmasq, pdns-server, pdnsd, and unbound) employ
> a technique to update /etc/resolv.conf with themselves. This updating
> happens after the respective cache is started. Usually any program reads
> /etc/resolv.conf once on the first DNS lookup. So all daemons started
> before the local DNS cache will either use a different server, or fail
> DNS resolution in all cases. A minority of services (avahi-daemon,
> fetchmail, postfix, sendmail, squid, and squid3) hook into resolvconf to
> reload their daemons when /etc/resolv.conf is changed by resolvconf.
> These daemons will not be affected by this problem. Many other services
> on the other hand will.

I think this is a somewhat different problem to the one you originally
state.  The real problem here is that resolv.conf is changing and
programs don't have the means to cope.

This is the result of a conflict in the system design.  Either (A)
resolv.conf is a static file, changeable only rarely and with much
restarting of services or rebooting.  Or (B) it is a dynamic file and
everyone who reads it needs the ability to detect when it changes and
perhaps some kind of push-update protocol.

The design used to be (A).  For convenience, some programs providing
DNS service have retrospectively decided that the design will be (B).

> What options do exist, besides adding update-libc.d scripts for each and
> every service?

I think the first thing to do is recognise the underlying problem.  To
fix this problem properly we need a coherent system design.  The two
designs lead to different sets of fixes.

A. resolv.conf is a static file which changes only very rarely.
Implications:
1. Existing DNS client applications do not need to change.
2. DNS service should always be provided at a fixed address
3. Therefore in the default installation this address should 
   refer to localhost.  Otherwise it cannot be redirected later
   as the network environment or installed package set changes.
4. Therefore in most installations there should be a local 
   proxy or cache.  It should use DHCP-provided, PPP-provided or
   similar, as a forwarder.  The local DNS provider address
   should be owned by whatever proxy or cache is installed.

B. resolv.conf is not static and may change due to network
   environment changes.
Implications:
1. All existing DNS applications must be modified to notice
   changes to resolv.conf.
2. Corollary: all existing DNS resolver libraries must be
   so modified.
3. This will be impractical unless a common mechanism with
   a convenient interface (and low impact on the rest of a
   program) is provided.  Hopefully resolvconf fits this bill.

I don't know exactly how impractical B2 is.  The libc's resolver is
probably a hard case because of the libc's low level in the protocol
stack.  Can we make it aware of resolvconf ?

The difficulty with plan A is probably B4.  Do we have a suitable
minimal proxy we can install, a way to reconfigure it based on dhcp
etc., and a means to displace it when something more substantial like
unbound is installed ?

Ian.


-- 
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/20918.158.894717.79...@chiark.greenend.org.uk

Re: Bug severity and private data disclosure

[Ian Jackson]

Vincent Lefevre writes ("Re: Bug severity and private data disclosure"):
> Note that this is a regression. Using the testing version (= stable
> currently) is fine w.r.t. this bug.

Oh, I see.  In that case I agree with you.  Have you asked the release
team ?  They are the right people for this escalation.

Ian.


-- 
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/20918.251.18792.187...@chiark.greenend.org.uk

Re: Bug severity and private data disclosure

[Andrey Rahmatullin]

On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote:
> > It's amazing how much simpler Debian life becomes if one simply ignores
> > bug severities entirely. Of course harder to do nearer to release, but
> > we live in a time of relative luxury right now…
> 
> This is important for apt-listbugs, which takes into account RC bugs by
> default 
Which too is not ideal: for example, I don't think users should care about
such RC bugs as FTBFS or some classes of licensing problems or any other
policy violations not having any visible effects on user systems.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Andrey Rahmatullin]

On Mon, Jun 10, 2013 at 11:17:26PM +0800, Chow Loong Jin wrote:
> > > > >>> * Package name: libsdl2-mixer
> > > > >>
> > > > >> Isn't this packaged already? You don't need to file WNPP bugs for 
> > > > >> SONAME
> > > > >> bumps...
> > > > > 
> > > > > It's a massive new major release.  Think perl5 vs perl6.
> > > > 
> > > > The point isn't that "it's in the archive", the point is that "you don't
> > > > need to deal with WNPP for new upstream versions of stuff you're already
> > > > doing".
> > > 
> > > I think it was more of "it's going to be a new source package."
> > Which is countered by "you don't need an ITP lock for stuff already having
> > a maintainer".
> 
> But the new source package doesn't have a maintainer until you upload it.
Are you afraid someone will start working on libsdl2 without asking the
maintainer of libsdl1?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Why not to let all DDs to execute "gb"-command

[Anton Gladky]

Thanks all for opinions! From my point of view, this tool will not be
used (hopefully) too often, but sometimes it is really necessary to try
it out before uploading a new source version.

On 06/09/2013 08:44 PM, Kurt Roeckx wrote:
> I have very mixed feelings about this.  I do in general think that
> would be good thing.  But I see many requests where I think it just
> doesn't make sense to me to retry it.
> 
> If things fail randomly, I really want to know _why_ it fails, and
> want to have that fixed.  I don't want to retry until it randomly
> works.  But I do understand that it sometimes might be hard to
> find why it sometimes fails.

Kurt, I do  really appreciate your work, and know, that it takes too
much time to handle such requests. But in most of cases the failing
archs are mips, mipsel, sparc and never "the most popular and used ones".

I understand, that it would be very good to have a nice package, which
always builds fine everywhere, but maintaining over 20 of them starts
one to set the priorities, what to do first: whether to fix one more
"real" bug or struggle with the random build-failures on the archs,
where the package probably will never be even started.

So, I think the developer should have a set of tools (including gb and
even "slight" removal commands), which allow him to do the most of
packaging work without worrying other teams/developers. And, of course,
those tools should be relatively secure not to break others work and the
whole archive. "gb" is a harmless in this case.

Thank you,

Anton



signature.asc
Description: OpenPGP digital signature

Re: Survey answers part 1: systemd has too many dependencies, …

[Henrique de Moraes Holschuh]

On Mon, 10 Jun 2013, Thomas Goirand wrote:
> On 06/10/2013 03:21 AM, Michael Stapelberg wrote:
> > Thomas Goirand  writes:
> >> In this blog post, you tell that it's possible not to use all the
> >> components of systemd. Then, the immediate question that pops to my
> >> mind: what are *your* intentions then, in Debian (or, said in another
> >> way, what would you like to do if you where the only one to decide)?
> >> Would you like to remove some components, or keep them all by default?
> > I don’t understand the intention behind that question. Could you clarify
> > so that I can give a proper answer please?
> 
> Let's say you decide. Let's say you set systemd by default in Debian.
> 
> Then which component would you install, and activate by default? Which
> component will you make only installable if the user decides to do it
> actively (for example using apt-get install)?

That is an uninteresting option.  There is no way we can afford to have two
different sets of features for PID 1 under the same name in Debian without
it causing support trouble we don't need.  So, please assume that every
"optional" PID 1 feature of systemd will be compiled in, and that only stuff
that can be disabled at runtime might be disabled.

It would be best to enhance
http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with
information about what runs on PID 1, and what runs after fork() and how
critical it is.

Also, it is extremely important to track down the full library dependency
chain for the systemd executable that runs as PID 1, and include any library
initialization code found in the entire chain in the analysis, otherwise the
analysis will be too incomplete to base any decisions on.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20130610182334.gb28...@khazad-dum.debian.net

Filtering bugs from apt-listbugs reports (was Re: Bug severity and private data disclosure)

[James McCoy]

On Jun 10, 2013 1:28 PM, "Andrey Rahmatullin"  wrote:
>
> On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote:
> > > It's amazing how much simpler Debian life becomes if one simply
ignores
> > > bug severities entirely. Of course harder to do nearer to release, but
> > > we live in a time of relative luxury right now…
> >
> > This is important for apt-listbugs, which takes into account RC bugs by
> > default
> Which too is not ideal: for example, I don't think users should care about
> such RC bugs as FTBFS

See /etc/apt/apt.conf.d/10apt-listbugs.  Bugs which have FTBFS in the
subject are already ignored. Similar filtering should be possible for other
categories of bugs as long as there's a standard way to recognize them.

James

Re: Filtering bugs from apt-listbugs reports (was Re: Bug severity and private data disclosure)

[Andrey Rahmatullin]

On Mon, Jun 10, 2013 at 02:40:17PM -0400, James McCoy wrote:
> > > > It's amazing how much simpler Debian life becomes if one simply
> ignores
> > > > bug severities entirely. Of course harder to do nearer to release, but
> > > > we live in a time of relative luxury right now…
> > >
> > > This is important for apt-listbugs, which takes into account RC bugs by
> > > default
> > Which too is not ideal: for example, I don't think users should care about
> > such RC bugs as FTBFS
> 
> See /etc/apt/apt.conf.d/10apt-listbugs.  Bugs which have FTBFS in the
> subject are already ignored. 
That line is commented here.

> Similar filtering should be possible for other
> categories of bugs as long as there's a standard way to recognize them.
Which probably doesn't exist.
I would like to filter out bugs about foreign architectures but I don't
think it's possible to distinguish them at all (apart from setting
usertags manually).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: security policy / root passwords

[Daniel Pocock]

On 10/06/13 16:51, Simon McVittie wrote:
> On 10/06/13 15:36, Timo Juhani Lindfors wrote:
>> Simon McVittie  writes:
>>> * ability to use system-modal prompting or a secure input path
>>>   (partially done by PK under GNOME Shell, likely to get better
>>>   under Wayland, not supported by sudo or su)
>>
>> Not relevant to the current discussion but this got me curious: can the
>> input path really be secure under X11?
> 
> It can at least be a bit more robust against accidentally typing your
> password into the wrong window (although perhaps not secure against
> deliberate abuse by a malicious application) by taking an input grab,
> like the various pinentry-* and ssh-askpass implementations do.
> 
> I'm not sure how far GNOME Shell goes with securing input to
> system-modal dialogs, but again, the fact that it's modal makes it a bit
> more robust against mistakes.

Every copy of jessie could be distributed with one of the red hoods
referred to in this article:

http://www.guardian.co.uk/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance

I presume it has some kind of electromagnetic shielding too.


-- 
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/51b627f7.4040...@pocock.com.au

Re: boot ordering and resolvconf

[Helmut Grohne]

No need to CC me here, see Mail-Followup-To.

On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
> I think this is a somewhat different problem to the one you originally
> state.  The real problem here is that resolv.conf is changing and
> programs don't have the means to cope.

Thanks for your analysis and pointing to the actual issue underneath.

> This is the result of a conflict in the system design.  Either (A)
> resolv.conf is a static file, changeable only rarely and with much
> restarting of services or rebooting.  Or (B) it is a dynamic file and
> everyone who reads it needs the ability to detect when it changes and
> perhaps some kind of push-update protocol.

As far as I can see, most of what resolvconf does is assuming (B) and
turning /etc/resolv.conf into a dynamic file. What would be left from
resolvconf when dropping assumption (B)?

> A. resolv.conf is a static file which changes only very rarely.
> Implications:
> 1. Existing DNS client applications do not need to change.
> 2. DNS service should always be provided at a fixed address
> 3. Therefore in the default installation this address should 
>refer to localhost.  Otherwise it cannot be redirected later
>as the network environment or installed package set changes.
> 4. Therefore in most installations there should be a local 
>proxy or cache.  It should use DHCP-provided, PPP-provided or
>similar, as a forwarder.  The local DNS provider address
>should be owned by whatever proxy or cache is installed.

So here we would likely introduce a virtual package, local-dns-resolver.
Likely resolvconf would depend on it. It would be provided by name
servers, that bind to localhost by default.

Shuffled the quotes:
> The difficulty with plan A is probably B4.  Do we have a suitable
> minimal proxy we can install, a way to reconfigure it based on dhcp
> etc., and a means to displace it when something more substantial like
> unbound is installed ?

I think that unbound actually might be that minimal proxy. When you
install it along with resolvconf, it will currently place itself in
/etc/resolv.conf (via resolvconf) as the sole nameserver and it will use
the name servers that were reported to resolvconf from dhcp or ppp as
upstream name servers. Another cache with similar capabilities in terms
of resolvconf integration is pdnsd. (Note that pdnsd doesn't do DNSSEC.)
For chroots we would likely need a i-know-that-there-is-a-cache package.

Strange thought: Would it be possible (on Linux) to add an iptables rule
to DNAT the local dns port? That would avoid the need for a proxy
altogether.

> B. resolv.conf is not static and may change due to network
>environment changes.
> Implications:
> 1. All existing DNS applications must be modified to notice
>changes to resolv.conf.
> 2. Corollary: all existing DNS resolver libraries must be
>so modified.
> 3. This will be impractical unless a common mechanism with
>a convenient interface (and low impact on the rest of a
>program) is provided.  Hopefully resolvconf fits this bill.
> 
> I don't know exactly how impractical B2 is.  The libc's resolver is
> probably a hard case because of the libc's low level in the protocol
> stack.  Can we make it aware of resolvconf ?

Actually the backend of getaddrinfo (from eglibc) already does a stat on
/etc/resolv.conf for every name resolution attemptd. (Correct me if I'm
wrong.) So programs will already use changed DNS servers in some cases.
It should be a matter of fixing the other resolvers here.

This would not solve the issue observed with ntp, because ntp treats the
EAI_SYSTEM returned by getaddrinfo as a permanent error. Kurt Roeckx
already indicated, that probably ntp should treat it as a temporary
error. Maybe resolvconf should mention 127.0.0.1 in the absence of any
other name server to avoid this situation?

As far as I can tell, we mostly are in the (B) situation. Anyway
clarification on which of these describes the system design to be
implemented would help. Where would we document this? Would it be part
of the policy?

How can we test programs to determine their compliance with the chosen
system design?

Helmut


-- 
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/20130610194534.ga14...@alf.mars

Re: Why not to let all DDs to execute "gb"-command

[Philipp Kern]

Hi,

On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
> So, I think the developer should have a set of tools (including gb and
> even "slight" removal commands), which allow him to do the most of
> packaging work without worrying other teams/developers. And, of course,
> those tools should be relatively secure not to break others work and the
> whole archive. "gb" is a harmless in this case.

it is not. If you rely on random successes of your build this is worse than not
providing a build at all. If there's a security issue, people will be forced to
spend time on the issue. Either the Security Team or by extension the Stable
Release Team, to get it built to finally include it into a point release or
leave it lingering forever in p-u-new because a test case fails.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Bug severity and private data disclosure

[Vincent Lefevre]

On 2013-06-10 23:28:28 +0600, Andrey Rahmatullin wrote:
> On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote:
> > This is important for apt-listbugs, which takes into account RC bugs by
> > default 
> Which too is not ideal: for example, I don't think users should care about
> such RC bugs as FTBFS or some classes of licensing problems or any other
> policy violations not having any visible effects on user systems.

For FTBFS bugs, this can already be done:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257873#41

It may be a bit more difficult to filter out other kinds of bugs
without false positives.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130610224604.gb30...@xvii.vinc17.org

Re: security policy / root passwords

[Jens Roder]

Hello,

just like to add that today this "feature" with the popup blocked my gnome 
within the suspend procedure, which I did not see but got a hot running laptop 
in the bag. When I opened the laptop again I saw the problem and when clicking 
on cancel, the laptop finally when to suspend. 

I think, just naming something a "feature" belongs more to microsoft behavior 
and shouldn't be copied in the linux world. A few things maybe useful but not 
for all people. Giving people the choice is the main point here. Whether you 
create a package that configures all with the funny new "features" and leave it 
to the user, if he wants this configuration or just uninstalls it to have a 
more conservative behavior for server setups.

I think it is a big mistake to design desktops with similar behaviors like one 
knows from the windows world. Most popup do not make any sense and interrupt 
people by working. Upcoming programs stealing the mouse, refocus, or resize are 
just annoying when writing a document.

The new gnome 3 desktop is nice, except it goes snow when too many windows are 
open (for a CTWM no problem) or it blocks the desktop switching because 
flashplayer freezes and gnome3 cannot access the graphics of the window. Nice 
features but cause serious problem, similar like this uninforming root password 
question and blocking the screen for wlan passwords. There is no need to block 
the screen as it can accidently pop up while writing a document and one would 
like to finish the sentence before typing a password. Such things come with 
force, rather than with the option of action which is a more elegant design. 
And another final problem are program menus which grap the mouse and when the 
program freezes, there is no way to release the mouse again execpt going out of 
X and into the consoles to kill the process. Recently skype's technical 
information window did not vanish. From gome menu I chose "close window" what 
it then did, but it took all with it and did freeze the desktop, even 
CTRL+ALT+F1 did not work to go out. Was a reboot and not nice 

I suggest to create window managers more independent from programs in order to 
increase stabilization. Also even when configured strict mouse behavior, the 
new upcoming program first graps the mouse and when moving it over the next 
window, it does not follow, here one has to click, after all is fine. I really 
suggest, give people more choice to configure things like they like or they are 
used to. X window system and window manager together have really nice features, 
just try not to make it like microsoft windows.

cheers
Jens

--
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/831ea06c08e40b459a98bff9939167e85a3b0...@cernxchg32.cern.ch

Re: security policy / root passwords

[Robert Holtzman]

On Mon, Jun 10, 2013 at 08:04:27AM +0800, Chow Loong Jin wrote:
> On Sun, Jun 09, 2013 at 01:06:40PM -0700, Robert Holtzman wrote:
> > [...]
> > In my gross stupidity this seems like a nonissue. How does a popup
> > asking for your root p/w differ from using the CLI, typing "su" and
> > being asked for the root p/w? I'm assuming that the popup was in
> > connection with a command (GUI) that legitimately would require root
> > privileges. A popup from a CLI command would wave a red flag.
> 
> Typing in your root p/w in a prompt on the CLI is manually initiated -- you 
> run
> a command that you know will prompt you for a password, and it prompts you.
>

That's what I said.
 
> Having a random popup in your face asking you for your password, with the 
> reason
> for its appearance not always immediately clear, could be bad because you 
> would
> then be desensitizing yourself to password prompts, and on one fine morning
> before the caffeine, you might just accidentally type your password into a
> malicious prompt that you didn't verify beforehand.

Exactly right.

-- 
Bob Holtzman
If you think you're getting free lunch, 
check the price of the beer.
Key ID: 8D549279


signature.asc
Description: Digital signature

Re: security policy / root passwords

[Michael Banck]

Hi Daniel,

On Mon, Jun 10, 2013 at 09:24:39PM +0200, Daniel Pocock wrote:
> Every copy of jessie could be distributed with one of the red hoods
> referred to in this article:
> 
> http://www.guardian.co.uk/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance
> 
> I presume it has some kind of electromagnetic shielding too.

Please keep it on topic.


Thanks,

Michael


-- 
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/20130610231158.gb26...@nighthawk.chemicalconnection.dyndns.org

Re: security policy / root passwords

[Michael Biebl]

Am 10.06.2013 11:10, schrieb Josselin Mouette:

> I consider it a bug, and one that we should aim to fix in the first
> wheezy point release.

nod. that said, the first point release is basically done, so this will
have to wait for 7.2


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

Re: Why not to let all DDs to execute "gb"-command

[Chow Loong Jin]

On Mon, Jun 10, 2013 at 10:43:57PM +0200, Philipp Kern wrote:
> Hi,
> 
> On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
> > So, I think the developer should have a set of tools (including gb and
> > even "slight" removal commands), which allow him to do the most of
> > packaging work without worrying other teams/developers. And, of course,
> > those tools should be relatively secure not to break others work and the
> > whole archive. "gb" is a harmless in this case.
> 
> it is not. If you rely on random successes of your build this is worse than 
> not
> providing a build at all. If there's a security issue, people will be forced 
> to
> spend time on the issue. Either the Security Team or by extension the Stable
> Release Team, to get it built to finally include it into a point release or
> leave it lingering forever in p-u-new because a test case fails.

It's not always the case of relying on random successes of your build. There are
valid cases -- for example, if a build-dep, or a dep of a build-dep had a bug
that prevented installation, and has just been fixed.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Chow Loong Jin]

On Mon, Jun 10, 2013 at 11:31:07PM +0600, Andrey Rahmatullin wrote:
> On Mon, Jun 10, 2013 at 11:17:26PM +0800, Chow Loong Jin wrote:
> > > > > >>> * Package name: libsdl2-mixer
> > > > > >>
> > > > > >> Isn't this packaged already? You don't need to file WNPP bugs for 
> > > > > >> SONAME
> > > > > >> bumps...
> > > > > > 
> > > > > > It's a massive new major release.  Think perl5 vs perl6.
> > > > > 
> > > > > The point isn't that "it's in the archive", the point is that "you 
> > > > > don't
> > > > > need to deal with WNPP for new upstream versions of stuff you're 
> > > > > already
> > > > > doing".
> > > > 
> > > > I think it was more of "it's going to be a new source package."
> > > Which is countered by "you don't need an ITP lock for stuff already having
> > > a maintainer".
> > 
> > But the new source package doesn't have a maintainer until you upload it.
> Are you afraid someone will start working on libsdl2 without asking the
> maintainer of libsdl1?

Not really, but I recall lintian complaining if you don't close an ITP in your
first changelog entry. Doesn't hurt to just file an ITP anyway, right? It just
makes your intention clear.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: boot ordering and resolvconf

[Chow Loong Jin]

On Mon, Jun 10, 2013 at 09:45:35PM +0200, Helmut Grohne wrote:
> [...]
> > A. resolv.conf is a static file which changes only very rarely.
> > Implications:
> > 1. Existing DNS client applications do not need to change.
> > 2. DNS service should always be provided at a fixed address
> > 3. Therefore in the default installation this address should 
> >refer to localhost.  Otherwise it cannot be redirected later
> >as the network environment or installed package set changes.
> > 4. Therefore in most installations there should be a local 
> >proxy or cache.  It should use DHCP-provided, PPP-provided or
> >similar, as a forwarder.  The local DNS provider address
> >should be owned by whatever proxy or cache is installed.
> 
> So here we would likely introduce a virtual package, local-dns-resolver.
> Likely resolvconf would depend on it. It would be provided by name
> servers, that bind to localhost by default.
> 
> Shuffled the quotes:
> > The difficulty with plan A is probably B4.  Do we have a suitable
> > minimal proxy we can install, a way to reconfigure it based on dhcp
> > etc., and a means to displace it when something more substantial like
> > unbound is installed ?
> 
> I think that unbound actually might be that minimal proxy. When you
> install it along with resolvconf, it will currently place itself in
> /etc/resolv.conf (via resolvconf) as the sole nameserver and it will use
> the name servers that were reported to resolvconf from dhcp or ppp as
> upstream name servers. Another cache with similar capabilities in terms
> of resolvconf integration is pdnsd. (Note that pdnsd doesn't do DNSSEC.)
> For chroots we would likely need a i-know-that-there-is-a-cache package.

If it helps any, NetworkManager in Ubuntu currently sets the hostname in
/etc/resolv.conf to 127.0.0.1 and runs dnsmasq locally. This /etc/resolv.conf is
copied into new schroots, allowing for approach A while allowing for dynamic
manipulation of where the DNS queries go to.

> Strange thought: Would it be possible (on Linux) to add an iptables rule
> to DNAT the local dns port? That would avoid the need for a proxy
> altogether.

Yes. A significant number of Linux-based consumer routers do this already, but
I'd rather we avoid this route if possible. This makes it rather hard to do
stuff like `dig @$other_server $hostname` for debugging purposes -- you'd need
root access to disengage the DNAT rule first. This setup should only be used for
administrators who want to completely forbid their users from querying other DNS
servers (short of starting a tunnel somewhere else).

> [...]

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: Survey answers part 1: systemd has too many dependencies, …

[Thomas Goirand]

On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 10 Jun 2013, Thomas Goirand wrote:
>> On 06/10/2013 03:21 AM, Michael Stapelberg wrote:
>>> Thomas Goirand  writes:
 In this blog post, you tell that it's possible not to use all the
 components of systemd. Then, the immediate question that pops to my
 mind: what are *your* intentions then, in Debian (or, said in another
 way, what would you like to do if you where the only one to decide)?
 Would you like to remove some components, or keep them all by default?
>>> I don’t understand the intention behind that question. Could you clarify
>>> so that I can give a proper answer please?
>>
>> Let's say you decide. Let's say you set systemd by default in Debian.
>>
>> Then which component would you install, and activate by default? Which
>> component will you make only installable if the user decides to do it
>> actively (for example using apt-get install)?
> 
> That is an uninteresting option.  There is no way we can afford to have two
> different sets of features for PID 1 under the same name in Debian without
> it causing support trouble we don't need.  So, please assume that every
> "optional" PID 1 feature of systemd will be compiled in, and that only stuff
> that can be disabled at runtime might be disabled.

If what you say above is right (I have no opinion on that yet, I just
trust what you say), then this renders the "systemd is modular" argument
completely useless, because practically, the user wont be able to
choose. Which is why I was asking specifically Michael about this, since
he raised the fact that systemd is modular and components can be disabled.

So my original question to Michael remains: what component should be
activated by default, which one could be optional, and how can these
options be enabled or disabled. I've heard about journald. which seems
controversial (I also don't have any option about it myself yet). Could
this one be optional, and not activated by default for example? What are
the systemd maintainers opinion about it?

Thomas


--
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/51b69a6e.6030...@debian.org

Bug#711927: ITP: dh-rebar -- helper tools for maintaining Erlang package which is using rebar

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: dh-rebar
  Version : 0.0.1
  Upstream Author : Nobuhiro Iwamatsu 
* URL : http://anonscm.debian.org/git/pkg-leofs/dh-rebar.git
* License : MIT/X
  Programming Lang: Perl
  Description : helper tools for maintaining Erlang package which is using 
rebar
  
  This package contains helper tools for maintaining Erlang Debian
  package which is using rebar.


-- 
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/20130611042549.3106.86622.reportbug@chimagu

Re: Survey answers part 1: systemd has too many dependencies, …

[Uoti Urpala]

Thomas Goirand wrote:
> On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote:
> > On Mon, 10 Jun 2013, Thomas Goirand wrote:
> >> Then which component would you install, and activate by default? Which
> >> component will you make only installable if the user decides to do it
> >> actively (for example using apt-get install)?
> > 
> > That is an uninteresting option.  There is no way we can afford to have two
> > different sets of features for PID 1 under the same name in Debian without
> > it causing support trouble we don't need.  So, please assume that every
> > "optional" PID 1 feature of systemd will be compiled in, and that only stuff
> > that can be disabled at runtime might be disabled.
> 
> If what you say above is right (I have no opinion on that yet, I just
> trust what you say), then this renders the "systemd is modular" argument
> completely useless, because practically, the user wont be able to
> choose. Which is why I was asking specifically Michael about this, since
> he raised the fact that systemd is modular and components can be disabled.

As I understand it, the point about modularity was brought up to clarify
misunderstandings about systemd architecture, not to suggest that the
Debian setup should give users the ability turn arbitrary things on or
off just for the sake of having more choices to make.

Some people apparently had various misunderstandings about systemd
"bloat", up to believing that it would have a huge collection of varying
functionality in PID 1. The "systemd is modular" argument shows what's
wrong with this "bloat" view. It still works even if Debian maintainers
decide to use all the modules. Your "user won't be able to choose" would
be relevant if the complaint had been that systemd doesn't provide
Gentoo users enough switches to turn on or off, but apparently that was
not a common complaint in the survey.



-- 
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/1370925376.18948.33.camel@glyph.nonexistent.invalid

Over 9000 Designs Priced As Low As Rs 100: Pick the One Complementing Your Looks!

[Johareez . com]

Johareez Special  Shop Now! (http://www.johareez.com/)
If you are having trouble viewing this email, click here to view it online. 
(http://www.johareez.com/newslettertemplates/434)
To ensure emails are delivered, please add promo_speci...@johareez.com to your 
address book.
http://www.johareez.com/   http://www.facebook.com/johareez 
http://twitter.com/johareez https://plus.google.com/114307163808030698022/posts 
http://blog.johareez.com/ http://pinterest.com/johareez/
http://www.johareez.com/shop/brand/silver-selection/jewellery/fashion-jewellery/rings-1#brand_0=brand%3ASilver+Selection&fr1_0=fr1%3DBrass&seq=&sort=&start=0
   
http://www.johareez.com/shop/brand/diamoure?type=offer#seq=desc&sort=offerprice&start=0
http://www.johareez.com/shop/brand/silverona/jewellery/fine-jewellery/jewellery-sets
http://www.johareez.com/shop/brand/good-times?type=offer
http://www.johareez.com/shop/brand/silver-selection/jewellery/fashion-jewellery/jewellery-sets-1#fr1_0=fr1%3DBrass&fr258_10=fr258%3DWhite&seq=&sort=&start=0
http://www.johareez.com/search/Bangles
http://www.johareez.com/search/Tungsten  
http://www.johareez.com/shop/brand/silverona/jewellery/fine-jewellery/earrings  
   http://www.johareez.com/search/Silver-Enamel-Charms
http://www.johareez.com/search/Glass%20Silver%20Pendant%20Sets?&catalog=1&tcat=1&cat=2&pcat=11#brand_1=brand%3ASilver+Selection&seq=&sort=&start=0
  http://www.johareez.com/search/Alphabetic-Pendant
http://www.johareez.com/shop/brand/silver-selection/jewellery/fashion-jewellery/ear-wraps
http://www.johareez.com/shop/brand/enamelour
http://www.johareez.com/search/Mangalsutra  

http://www.johareez.com/search/Mother-of-Pearl-Jewellery
http://www.johareez.com/search/Micro-Pave-American-Diamond-Jewellery 
http://www.johareez.com/search/Stainless%20Steel%20Ring?&catalog=1&tcat=1&cat=2&pcat=14#fr1_0=fr1%3DStainless+Steel&fr258_0=fr258%3DBlack&fr258_1=fr258%3DBlue&fr258_2=fr258%3DGreen&seq=&sort=&start=0
 http://www.johareez.com/search/loose-gemstone
http://www.johareez.com/search/Crystal-Silver-Jewellery#start=0 

http://www.johareez.com/search/Two-Tone-Plated?&catalog=1&tcat=1&cat=2&pcat=14#brand_1=brand%3ASilver+Selection&seq=&sort=&start=0
http://www.johareez.com/search/MEN%27S?&catalog=1&tcat=1&cat=4&pcat=21
http://www.johareez.com/shop/brand/suraabi#start=0
http://www.johareez.com/search/Navratna-Pendant-Sets

http://www.johareez.com/search/Pearl%20Jewellery?&catalog=1&tcat=1&cat=4
http://www.johareez.com/search/Bunch-Necklaces   
http://www.johareez.com/search/leather-jewellery
   http://www.johareez.com/search/Anklets
http://www.johareez.com/search/Raani-Haar   

http://www.johareez.com/search/Cubic-Zircon-.925-Sterling-Silver-Two-Side-Ring
http://www.johareez.com/search/toe-ring
http://www.johareez.com/search/Enamel-Cufflinks
http://www.johareez.com/search/925-Sterling-Silver-Necklace?&catalog=1&tcat=1&cat=2&pcat=12&scrw=1600&scrh=900#brand_2=brand%3AJohareez&seq=&sort=&start=0
  http://www.johareez.com/search/Marcasite-Silver-Jewellery#start=0
http://www.johareez.com/search/Enamel-Brooches   
http://www.johareez.com/search/Murano-Glass-Jewellery   
   
http://www.johareez.com/search/Crystal-.925-Sterling-Silver-Ring?&catalog=1&tcat=1&cat=2&pcat=14#seq=desc&sort=offerprice&start=0
ISO 9001:2008 Registered Company  |   Secured Shopping Guaranteed  |  
Certificate of Authenticity http://www.facebook.com/johareez 
http://twitter.com/johareez https://plus.google.com/114307163808030698022/posts 
http://blog.johareez.com/ http://pinterest.com/johareez/
Other Featured Promotions:
- Refer a Friend and SAVE 10% on your order! Learn more 
(http://www.johareez.com/spread_a_word.php) .

Questions? Contact Customer Service (mailto:supp...@johareez.com) .
Please do not reply to this e-mail as we are not able to respond to messages 
sent to this address. Due to the incredible values being offered, all clearance 
and special-priced merchandise is excluded from this promotion. Excludes prior 
sales, certified loose diamonds, select brands, and gift certificates, cannot 
be combined with other offers. We reserve the right to cancel an order due to 
unauthorized, altered or ineligible use of discount and to modify or cancel 
this promotion due to system error or unforeseen problems.

This message was sent from: Johareez.com. Auctions Pvt. Ltd.
C-1, IGM Tower, Gopinath Marg, New Colony, MI Road, Jaipur - 302001 Raj

Re: Survey answers part 1: systemd has too many dependencies, …

[Tollef Fog Heen]

]] Thomas Goirand 

> If what you say above is right (I have no opinion on that yet, I just
> trust what you say), then this renders the "systemd is modular" argument
> completely useless, because practically, the user wont be able to
> choose. Which is why I was asking specifically Michael about this, since
> he raised the fact that systemd is modular and components can be disabled.

The primary point about the modularity is to limit what happens in init
itself, not to have optional modules if it can be avoided.

> So my original question to Michael remains: what component should be
> activated by default, which one could be optional, and how can these
> options be enabled or disabled. I've heard about journald. which seems
> controversial (I also don't have any option about it myself yet). Could
> this one be optional, and not activated by default for example? What are
> the systemd maintainers opinion about it?

I believe I already answered this, so I'm not sure why you're asking
again.

-- 
Tollef Fog Heen, with his systemd maintainer hat on
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/87li6hqkdv@xoog.err.no