Re: List of FTBFS in Ubuntu

[Olaf van der Spek]

On Fri, Dec 10, 2010 at 2:38 AM, Fernando Lemos  wrote:
> Hi Olaf, Roger
>
> On Thu, Dec 9, 2010 at 11:00 AM, Olaf van der Spek  
> wrote:
> [...]
>>> Now, pkg-config isn't standardised /either/, but it's useful because
>>> it will work with any standards-conforming compiler.  It's just a
>>> generalisation of existing practice (in the form of foo-config
>>> scripts generated during a package build).
>>
>> Pkg-config probably isn't bad, but it does increase the complexity of
>> build script. Especially compared to auto linking.
>
> Correct me if I'm wrong, but I don't think implementing auto linking
> support in GCC is a realistic goal. I can imagine there are lots of
> technical and non-technical issues involved, it's certainly not
> something that can be accomplished in the short term.

Do we need a short term solution?
I agree it can't be done short term, but why is it unrealistic?

>>> But this is all moot.  I've written the pkg-config support into the
>>> auto-link header, and we just need to integrate it into the build
>>> system to get the job done.
>>
>> How does pkg-config handle the selection of the threading variant?
>> Toolset-variant? Seems it's hard-coded to a single variant.
>
> Yeah, take a look at the comments in the report Roger linked to. It
> looks like we can't handle multiple variants with pkg-config. I don't
> think this is a major problem for the time being, though, as there's a
> single variant in Debian and I imagine that's also the case for most
> other distributions.
>
> I think proper pkg-config support would be fantastic. I'm wondering if
> this support could be patched downstream in case upstream rejects or
> ignores the patches Roger submitted. I'll adapt btag's build system to
> use pkg-config for Boost as soon as this enters unstable.
>
> Regards,
>
>
> --
> 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/aanlktipwhkthrmama9scwsql-yy7wca6rz6p7bhv...@mail.gmail.com
>
>


--
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/aanlkti�gh4rbtepflooo+pl7y-iiwolyar5boob...@mail.gmail.com

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Michael Tautschnig]

(CC'ed debian-devel as this was a not-so-well coordinated MBF without
announcement to debian-devel, dd-list, usertags; so maybe at least further
discussion can happen there)

Hi Florian,

[...]
> 
> These lines from this package's maintainer scripts suggest that it likely
> is affected by the vulnerability:
> 
> ---
> chmod 640 $FRESHCLAMLOGFILE
> chown "$dbowner":adm $FRESHCLAMLOGFILE
> ---
> 

What is wrong about these two lines? And even from ...

[...]

> For some further details please see my announcement of this mass
> filing on debian-qa:
> 
> http://lists.debian.org/debian-qa/2010/11/msg00024.html
> 
[...]

... I don't quite understand why this would be problem specific to one of the
packages you did the MBF for. If I get the idea of your exploit right, you
replace the log file by a symlink to a root-owned file, and in some mysterious
way you then seem to be able to overwrite the root-owned file. Well, it will
suffice for the evil person to be in adm group, you don't need to be $package
user for doing that.

But ok, you don't even claim there's a specific bug in our package, it's all
logrotate's fault. Assuming clamav uses logrotate in a sane way (I wouldn't no
of anyone claiming it does not), what should we do? Drop log rotation? Cool,
thanks, then the security-tagged bug report against clamav is actually justified
because it'll soon fill up your disk, possibly resulting in a DoS. Come up with
it's own cron-job for log rotation? No, thank you.

At present, the only thing I'd plan to do is to either reassign this bug to
logrotate or simply close it.

Best regards,
Michael



pgpx3y5WyWN24.pgp
Description: PGP signature

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Olaf van der Spek]

On Fri, Dec 10, 2010 at 9:43 AM, Michael Tautschnig  wrote:
>> These lines from this package's maintainer scripts suggest that it likely
>> is affected by the vulnerability:
>>
>> ---
>> chmod 640 $FRESHCLAMLOGFILE
>> chown "$dbowner":adm $FRESHCLAMLOGFILE
>> ---
>>
>
> What is wrong about these two lines? And even from ...

It suggests the daemon itself creates the file. Copytruncate suggests
logrotate also creates the file.
Logrotate runs as root, so if the attacker (running as daemon user)
creates the symlink, logrotate might overwrite an arbitrary file (I
guess).

Olaf


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

Re: privilege escalation and potential data loss in logrotate

[Sandro Tosi]

(copying the thread to debian-devel, where mass-bug-fills *has to* be
discussed, not d-qa)

On Sat, Nov 20, 2010 at 08:23, Florian Zumbiehl  wrote:
> Hi,
>
> The short summary:
>
> 1. There is a privilege escalation vulnerability in stable's logrotate,
>   verified to work for switching from the postgres user to root, probably
>   affecting the system users of about 40 packages. A fix for this has
>   been in testing for about a year now, the original bug report and a
>   first patch have been in the bug tracker for about four years now.
>
> 2. The fix in testing introduces a regression that can cause loss of
>   log messages where no such loss was possible before. A fix for this
>   regression has been available to the maintainer and the security team
>   for about a year now but has not been integrated so far.
>
> Got your attention? Good, let me elaborate a bit:
>
> First of all, it's bug #388608. Unfortunately, quite a bit of the
> interesting communication was private, either with the maintainer, or
> with the security team, or both, so I can't reference it in some public
> location, and just pasting my own text fragments into this mail probably
> would not be particularly enlightening either.
>
> As far as the vulnerability is concerned, I guess the available
> information at least is sufficient to get some clue as to what the
> problem is and how serious it is.
>
> Regarding the regression in the fix: With previous versions, it was
> guaranteed that unless you used the copytruncate option, you would not
> ever lose log messages due to rotation. With the fix, this guarantee
> does not exist anymore in cases where the program writing to the log
> file as well as logrotate may create the log file when it doesn't exist
> (which is a common setup, and which cannot even be avoided in many
> cases).
>
> Now, the problem is that I don't really recall all the details anymore
> either, and it would be some effort to get into it again. Given the
> little success my efforts have had so far, I am not willing to put in
> that work for potentially no gain. If you have any specific questions,
> feel free to ask, I'll do my best to give you the information I have,
> and if I see that this is actually going somewhere, maybe I'm even going
> devote some more cycles to this again.
>
> If I don't see any solution emerging in a reasonable time frame, my next
> step would be a more-or-less mass filing against all those packages that
> some rough analysis suggests are affected by either the vulnerability
> or the regression so that their maintainers can take measures to work
> around the problem if they want to.

So, instead of fixing logrotate in stable (did you contact release
team to ask if a NMU is possible?), so just one package, you preferred
to file 32 bugs[1] for all the affected packages? also with phrases
like "I don't remember how I made the tests, or if the bugs are still
there, but trust me there's a problem" it's kinda upsetting and/or
unprofessional.

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=florz%40florz.de#_0_1_4

If you really care about this problem, which is nice, try to get
logrotate fixed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
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/aanlktikz7u+2bxzjwdns9fndeveg-=hfeems3l-zi...@mail.gmail.com

Re: privilege escalation and potential data loss in logrotate

[Paul Martin]

On Fri, Dec 10, 2010 at 10:17:53AM +0100, Sandro Tosi wrote:

> If you really care about this problem, which is nice, try to get
> logrotate fixed.

As I have said before, I do welcome patches that don't break existing
functionality or introduce new race conditions.

None of my emails to Florian are private, and I would be happy for him
to quote them if I am also allowed to quote his responses.

-- 
Paul Martin 


-- 
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/20101210100022.ga24...@nowster.org.uk

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Holger Levsen]

Hi,

On Freitag, 10. Dezember 2010, Michael Tautschnig wrote:
> (CC'ed debian-devel as this was a not-so-well coordinated MBF without
> announcement to debian-devel, dd-list, usertags; so maybe at least further
> discussion can happen there)

thanks for that.

I've reassigned all these bugs to logrotate and merged them with the original 
bug. Yawn.


cheers,
Holger




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

Re: privilege escalation and potential data loss in logrotate

[Olaf van der Spek]

On Fri, Dec 10, 2010 at 11:00 AM, Paul Martin  wrote:
> On Fri, Dec 10, 2010 at 10:17:53AM +0100, Sandro Tosi wrote:
>
>> If you really care about this problem, which is nice, try to get
>> logrotate fixed.
>
> As I have said before, I do welcome patches that don't break existing
> functionality or introduce new race conditions.

That doesn't really solve the problem, does it?

Olaf


-- 
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/aanlktik++ghb1zpyowdhg+1ikapvrkxnoy_tgeoa_...@mail.gmail.com

Re: List of FTBFS in Ubuntu

[Roger Leigh]

On Thu, Dec 09, 2010 at 02:00:24PM +0100, Olaf van der Spek wrote:
> On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh  wrote:
> >> I was wondering why you considered the auto linking stuff to be so 
> >> horrible.
> >> IMO the best solution would be to get auto link support into GCC too.
> >
> > It's non standard
> > - it's not specified by ISO C
> > - it's not specified by SUS/POSIX
> 
> So?

When we write code, we write it with the intention and expectation
that it will be built using a standards-conforming compiler.  I.e.
one which implements the C and/or C++ language specification, and
which also implements standard UNIX command-line options.  While
platform- specific features are provided by various platforms, the
basic behaviour of the compiler and linker are specified by POSIX/SUS.

As an example, look at the SUSv3 specification for the "c99"
program (linked to gcc on GNU/Linux).  How to compile and link a
program is directly specified here.  You can't change that without
breaking a fundamental part of what a GNU/Linux system *is*.  If it's
no longer SUSv3 conforming, it's broken, because most of the programs
built on Debian rely upon this standard.

> > It's not portable
> > - it uses vendor-specific #pragma magic
> >
> > It's fragile
> > - every header must include the auto-link magic, either directly or
> >  indirectly.  If you forget to do this just once in a single file,
> >  linking will break
> 
> Sounds like an easy-to-solve hypothetical problem.

Easy to fix once you notice a problem.  The issue is how maintainable
it would be in practice.  i.e. how often will people break it when
refactoring code, adding new headers etc..  It could be a significant
burden.

> > If it were incorporated into GCC, we still couldn't use it
> > - it's not backward compatible with other UNIX compilers
> > - it's not backward compatible with itself
> 
> Who is we?
> Do we need that kind of backwards compatibility?

Yes, without a doubt.  If this was used by a project as the linking
mechanism, you wouldn't be able to build on any past release of Debian,
or any other GNU/Linux distribution.  You also wouldn't be able to
build on any other UNIX system.  It's not a feasible short-term goal.

Such a change should really go via the standards committees if
you really want support for such a feature.  But this is a long-
term solution, and would take years.  Also, the standards committees
tend to standardise existing practice, so an implementation of this
behaviour in GCC and binutils (ld/gold) would be a prerequisite.

As I mentioned at the top of this mail, standards conformance is a
big deal.  If we break that, we lose portability.  If this is done
through a revision to an existing standard (and SUS is probably the
best place for this; the C/C++ standards don't AFAICT involve
themselves in tool specs), support becomes much easier since it will
be adopted across all conforming platforms.

> > Now, pkg-config isn't standardised /either/, but it's useful because
> > it will work with any standards-conforming compiler.  It's just a
> > generalisation of existing practice (in the form of foo-config
> > scripts generated during a package build).
> 
> Pkg-config probably isn't bad, but it does increase the complexity of
> build script. Especially compared to auto linking.

It integrates trivially with autoconf-using projects
(PKG_CHECK_MODULES).  It's also trivial to support in projects using
plain make or other build systems
(FOO_LIBS=$(shell pkg-config --libs foo)).

But the main thing going for it is that it works with existing
standards-conforming toolchains right now.  It doesn't require adding
non-standard compiler extensions.

> > But this is all moot.  I've written the pkg-config support into the
> > auto-link header, and we just need to integrate it into the build
> > system to get the job done.
> 
> How does pkg-config handle the selection of the threading variant?
> Toolset-variant? Seems it's hard-coded to a single variant.

This is correct.  The auto-link support could be adapted to
encode the variant into the pkg-config .pc filename and/or the
library names.  Upstream specifically do not want to support
multiple .pc files (see the upstream bug report and mailing list
thread).

People who do need this can build multiple versions, install them
into different prefixes and then set PKG_CONFIG_PATH to select
the variant they want at configure time.  Unlike Boost, which has
to support Windows, we can support multiple versions very easily
without the need for encoding additional information into the library
name.


Regards,
Roger

-- 
  .''`.  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: List of FTBFS in Ubuntu

[Olaf van der Spek]

On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh  wrote:
>> So?
>
> When we write code, we write it with the intention and expectation
> that it will be built using a standards-conforming compiler.  I.e.
> one which implements the C and/or C++ language specification, and
> which also implements standard UNIX command-line options.  While
> platform- specific features are provided by various platforms, the
> basic behaviour of the compiler and linker are specified by POSIX/SUS.
>
> As an example, look at the SUSv3 specification for the "c99"
> program (linked to gcc on GNU/Linux).  How to compile and link a
> program is directly specified here.  You can't change that without
> breaking a fundamental part of what a GNU/Linux system *is*.  If it's
> no longer SUSv3 conforming, it's broken, because most of the programs
> built on Debian rely upon this standard.

Adding support for auto linking to g++ (via pragma or some other way)
doesn't mean g++ no longer conforms to SUSv3 or POSIX.

>> Sounds like an easy-to-solve hypothetical problem.
>
> Easy to fix once you notice a problem.  The issue is how maintainable
> it would be in practice.  i.e. how often will people break it when
> refactoring code, adding new headers etc..  It could be a significant
> burden.

Works pretty well for Boost.

>> > If it were incorporated into GCC, we still couldn't use it
>> > - it's not backward compatible with other UNIX compilers
>> > - it's not backward compatible with itself
>>
>> Who is we?
>> Do we need that kind of backwards compatibility?
>
> Yes, without a doubt.  If this was used by a project as the linking
> mechanism, you wouldn't be able to build on any past release of Debian,
> or any other GNU/Linux distribution.  You also wouldn't be able to
> build on any other UNIX system.  It's not a feasible short-term goal.

It's a long-term goal.

> Such a change should really go via the standards committees if
> you really want support for such a feature.  But this is a long-
> term solution, and would take years.  Also, the standards committees
> tend to standardise existing practice, so an implementation of this
> behaviour in GCC and binutils (ld/gold) would be a prerequisite.

Isn't that exactly what I'm trying to achieve?

> As I mentioned at the top of this mail, standards conformance is a
> big deal.  If we break that, we lose portability.  If this is done
> through a revision to an existing standard (and SUS is probably the
> best place for this; the C/C++ standards don't AFAICT involve
> themselves in tool specs), support becomes much easier since it will
> be adopted across all conforming platforms.

I agree

>> Pkg-config probably isn't bad, but it does increase the complexity of
>> build script. Especially compared to auto linking.
>
> It integrates trivially with autoconf-using projects
> (PKG_CHECK_MODULES).  It's also trivial to support in projects using
> plain make or other build systems
> (FOO_LIBS=$(shell pkg-config --libs foo)).

How about Windows?

> But the main thing going for it is that it works with existing
> standards-conforming toolchains right now.  It doesn't require adding
> non-standard compiler extensions.

Again, I'm not saying pkg-config is bad.

> People who do need this can build multiple versions, install them
> into different prefixes and then set PKG_CONFIG_PATH to select
> the variant they want at configure time.  Unlike Boost, which has
> to support Windows, we can support multiple versions very easily
> without the need for encoding additional information into the library
> name.

You're encoding it in the path instead, which seems worse.

Olaf


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

Bug#606493: gnome-screensaver: Fails to authenticate users with NIS on amd64

[Dietrich Clauss]

Mark Brown wrote:
> The most likely culprit here would seem to be a glibc issue or a local
> misconfiguration caused during the upgrade.

Oh, I used the term 'upgrade', which was misleading.

The system where the bug occurs is an amd64 squeeze installation from
scratch, done last week.  (Upgrade from one arch to another is not
possible, so I had to reinstall.)

- Dietrich

-- 
We need multiarch multiarch multiarch multiarch multiarch mul...



signature.asc
Description: Digital signature

Re: List of FTBFS in Ubuntu

[Vincent Danjean]

  Hi,

On 10/12/2010 13:59, Olaf van der Spek wrote:
> On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh  wrote:
>> People who do need this can build multiple versions, install them
>> into different prefixes and then set PKG_CONFIG_PATH to select
>> the variant they want at configure time.  Unlike Boost, which has
>> to support Windows, we can support multiple versions very easily
>> without the need for encoding additional information into the library
>> name.
> 
> You're encoding it in the path instead, which seems worse.

  I'm coming here as a programmer that knows some things about
libraries and linking on Linux (but nothing on windows nor about
boost).
  If, as a programmer, I want to use boost, what do I have to know ?
(ie, what should I decide ?) How this can be done actually or in the
future is not my point for now.

  If I correctly understand from this discussion, when I want to
compile a program using boost:
[A] I need to know which part of boost I want to use (filesystem, ...)
  Comment: it is normal and expected when using a group of libraries
[B] I do not need select a version
  Comment: I want to use the currently installed version (hopefully the
last). If really needed, I can force the build with another version by
setting up paths (INCLUDEPATH, LD_LIBRARY_PATH, "-I" and "-L" flags, ...)
[C] selection of the "tool chain"
  Comment: this seems to be very boost specific!
For what I saw, there is the MT/no thread choice. Are there others ?
  It is possible that boost will be used by different libraries that will
  built a single program. So, different versions by toolchain must work
  together in a single program. In particular, nowadays, a library using
  boost must suppose that it will be used in a multithreaded program.
Perhaps a distribution will only provide a single version (MT in this
  case, as for lots of other libraries)



  Now, if we want to use pkg-config (and I think it is a must for such a
general-purpose library), the choices that must be done by boost users
must be encoded into .pc name (and only them).
For [A], it will be the library/'part of boost' name
For [B]: none
For [C], it will be a suffix if this is really needed (but, here again,
  support for MT is really a must nowadays for system libraries: are there
  other toolchain selection?)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4d0238f5.4040...@free.fr

Re: List of FTBFS in Ubuntu

[Olaf van der Spek]

On Fri, Dec 10, 2010 at 3:28 PM, Vincent Danjean  wrote:
> [C] selection of the "tool chain"
>  Comment: this seems to be very boost specific!

Not necessary at the moment.

>    For what I saw, there is the MT/no thread choice. Are there others ?
>  It is possible that boost will be used by different libraries that will
>  built a single program. So, different versions by toolchain must work
>  together in a single program. In particular, nowadays, a library using
>  boost must suppose that it will be used in a multithreaded program.
>    Perhaps a distribution will only provide a single version (MT in this
>  case, as for lots of other libraries)

I think that's the case at the moment.

>  Now, if we want to use pkg-config (and I think it is a must for such a
> general-purpose library), the choices that must be done by boost users
> must be encoded into .pc name (and only them).
> For [A], it will be the library/'part of boost' name
> For [B]: none
> For [C], it will be a suffix if this is really needed (but, here again,
>  support for MT is really a must nowadays for system libraries: are there
>  other toolchain selection?)

See 
http://www.boost.org/doc/libs/1_45_0/more/getting_started/unix-variants.html#library-naming
But ATM you can just do -lboost_filesystem -lboost_system.

The problem is that using some parts of filesystem will mean you also
need to link to system.

Olaf


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

Re: List of FTBFS in Ubuntu

[Vincent Danjean]

On 10/12/2010 16:59, Olaf van der Spek wrote:
> On Fri, Dec 10, 2010 at 3:28 PM, Vincent Danjean  wrote:
>> [C] selection of the "tool chain"
>>  Comment: this seems to be very boost specific!
> 
> Not necessary at the moment.
> 
>>For what I saw, there is the MT/no thread choice. Are there others ?
>>  It is possible that boost will be used by different libraries that will
>>  built a single program. So, different versions by toolchain must work
>>  together in a single program. In particular, nowadays, a library using
>>  boost must suppose that it will be used in a multithreaded program.
>>Perhaps a distribution will only provide a single version (MT in this
>>  case, as for lots of other libraries)
> 
> I think that's the case at the moment.
> 
>>  Now, if we want to use pkg-config (and I think it is a must for such a
>> general-purpose library), the choices that must be done by boost users
>> must be encoded into .pc name (and only them).
>> For [A], it will be the library/'part of boost' name
>> For [B]: none
>> For [C], it will be a suffix if this is really needed (but, here again,
>>  support for MT is really a must nowadays for system libraries: are there
>>  other toolchain selection?)
> 
> See 
> http://www.boost.org/doc/libs/1_45_0/more/getting_started/unix-variants.html#library-naming

Thank for the pointer. So, in my opinion, a (unix) distribution will only
provide one variant of library (the other seems to have no interest for
developer of external application). And if, for specific needs (for a user,
not for the distribution), other variants are needed, as for all other
libraries that can be compiled with debug, ..., it can be done in specific
prefixes (/opt/debug/...) instead of /usr prefix.

> But ATM you can just do -lboost_filesystem -lboost_system.

Here, you are wrong. If I want to use the 'filesystem' part of boost,
I (as a user of the library) must be able to find all required info
only from the part of boost that I want to use.
"pkg-config --libs boost_filesystem" is one standard way to do it.
'boost-config --libs filesystem' can be another one.
autolink could also be a solution (but I'm not convinced at all by
this feature as described in this thread)
  But hardcoding in sources the fact that you need
"-lboost_filesystem -lboost_system" (ie what must be done currently) is
a wrong approach (in my opinion).

> The problem is that using some parts of filesystem will mean you also
> need to link to system.

  Yes, so boost needs to provide a way to retrieve this info when
compiling a program/library using boost.

  Regards,
Vincent

> 
> Olaf



-- 
Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot
Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann
Email: vincent.danj...@imag.fr   38330 Montbonnot Saint Martin


-- 
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/4d02770a.9030...@free.fr

Re: apt-diff: a tool to diff filesystem content against APT

[Tristan Schmelcher]

On Thu, Dec 9, 2010 at 11:12 PM, Goswin von Brederlow  wrote:
> Osamu Aoki  writes:
>
>> On Fri, Dec 10, 2010 at 12:06:45AM +0900, Osamu Aoki wrote:
>>> Hi,
>>>
>>> On Wed, Dec 08, 2010 at 12:52:28PM -0800, Tristan Schmelcher wrote:
>>> > On Tue, Dec 7, 2010 at 11:30 PM, Goswin von Brederlow  
>>> > wrote:
>>> > > Tristan Schmelcher  writes:
>>> > >>> how does it deal with configurations generated in postinstall?
>>> > I find debsums to be too basic for my needs. apt-diff is my attempt to
>>> > improve upon it. I often want to answer the question "how does package
>>> > X on my machine compare to a pristine installation?" debsums only
>>> > gives part of the answer. It can't check files that are missing
>>> > md5sums (which includes a lot of conffiles)
>>                                      ~
>>> Wrong.
>>
>> OOps..  I now see your point.  Sorry.
>>
>>> If you configure debsum correctly following manpage, md5sums are
>>> available for all packages.  Use -g option to initialize it and make
>>> sure to set the debconf boolean value debsums/apt-autogen to be "true".
>>> I understand that this is an exra hussle.
>>
>> This is talking about files missing md5sums due to packaging practice of
>> the maintainer.  conffiles are not debsums interest.
>
> Does debsums support ucf? Can it support ucf?
>
> What I mean is that often generated conffiles are installed with ucf and
> ucf keeps track of the original generated checksum and the possibly
> localy modified file and such. Does/could debsums tap into that info to
> find generated conffiles that were changed?

It would be pretty easy to tap into--the md5sums are all in
/var/lib/ucf/hashfile and it's already in the format used by md5sum
-c. But that still leaves a lot to be desired. On my machine there are
only 26 entries in that file, whereas there are 1663 conffiles without
md5sums.* As far as I know there's no metadata available to check the
integrity of those files--they have to be compared to the original
files in the .deb as apt-diff does.

*As determined by this script:

for file in /var/lib/dpkg/info/*.conffiles; do
  for line in $(cat $file); do
line=$(sed -r 's/^\///' <<<$line)
md5sums=$(sed -r 's/conffiles/md5sums/' <<<$file)
if ! grep -qF $line $md5sums; then
  echo $line
fi
  done
done | wc

>
>> By the way, etckeeper is the way to track /etc history to me.  Some
>> conffile are generated by postinst.  So not all files in /etc are in
>> package as file.
>>
>>> Making this easy is step in right direction as long as it is written in
>>> effective way.  (In order to improve debsum, we should know it well.
>>> Debsum tries to avoid downloading package as much as possible.
>>
>> Osamu)
>
> MfG
>        Goswin
>


--
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/aanlktikewzhqu8efobe1cfpp-+iga-okukqh_zwp3...@mail.gmail.com

Re: Bug#606449: ITP: cnagios -- terminal interface for viewing nagios host and service objects

[Joachim Breitner]

Hi Bernhard,

Am Donnerstag, den 09.12.2010, 12:03 +0100 schrieb Bernhard Hauser:
> Package: wnpp
> Severity: wishlist
> Owner: Bernhard Hauser 
> 
> * Package name: cnagios
>   Version : 0.27
>   Upstream Author : Steve Rader 
> * URL : ftp://noc.hep.wisc.edu/pub/src/cnagios/
> * License : LICENSE-File within the tar.gz-archive
>   Programming Lang: C, Perl
>   Description : terminal interface for viewing nagios host and service 
> objects
> 
> Cnagios is a full-screen terminal interface for viewing Nagios HOST
> and SERVICE objects, and the durations of their current states.  It's 
> lightning fast because it's written in C using the curses library.
> And it's super flexible because it uses the perl C library to shorten 
> and alter host, service and plugin output and filter the displayed 
> HOSTs or SERVICEs.

thanks contributing this package. I think the description could need
some rewording; it sounds more like advertising than an objective
description.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: privilege escalation and potential data loss in logrotate

[Florian Zumbiehl]

Hi,

> On Fri, Dec 10, 2010 at 10:17:53AM +0100, Sandro Tosi wrote:
> 
> > If you really care about this problem, which is nice, try to get
> > logrotate fixed.
> 
> As I have said before, I do welcome patches that don't break existing
> functionality or introduce new race conditions.

Let me quote from my yet-unanswered reply to you on debian-qa two weeks
ago:

| If you were so kind to point out what part of my fix is not working?

> None of my emails to Florian are private, and I would be happy for him
> to quote them if I am also allowed to quote his responses.

Let me quote from my yet-unanswered reply to you on debian-qa two weeks
ago:

| I don't currently see the use (fragments out of context aren't all that
| helpful and just quoting the whole thread would be a bit tedious to
| follow, I suppose)--but I'm fine with you quoting what I've written
| if you think there is any use for it.

Florian


-- 
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/20101211011122.gf3...@florz.florz.dyndns.org

Re: privilege escalation and potential data loss in logrotate

[Florian Zumbiehl]

Hi,

> (copying the thread to debian-devel, where mass-bug-fills *has to* be
> discussed, not d-qa)

As such I would suggest completely moving this thread over to d-devel
and dropping d-qa from subsequent mails.

[...]
> > If I don't see any solution emerging in a reasonable time frame, my next
> > step would be a more-or-less mass filing against all those packages that
> > some rough analysis suggests are affected by either the vulnerability
> > or the regression so that their maintainers can take measures to work
> > around the problem if they want to.
> 
> So, instead of fixing logrotate in stable (did you contact release
> team to ask if a NMU is possible?), so just one package, you preferred
> to file 32 bugs[1] for all the affected packages? also with phrases
> like "I don't remember how I made the tests, or if the bugs are still
> there, but trust me there's a problem" it's kinda upsetting and/or
> unprofessional.

Would you mind pointing out where I wrote this particular sentence or
alternatively retracting that quote? Thanks.

Also, apparently I haven't stated this with sufficient clarity yet: I have
been trying to get logrotate fixed for over four years now by supplying
patches, being responsive to the maintainer, notifying the security team
of the issue, trying to get a discussion started on d-qa, all with very
limited success. So much for upsetting and unprofessional.

Also: No, I didn't. I'm sorry if I didn't find the right way to do things
in debian's bureaucracy, but I am not a debian developer and I tried
to be careful--and at least logrotate's maintainer obviously knew what
I was up to, plus anyone on d-qa who read my mail there also could have
pointed me in the right direction, so I won't take the blame for that.

> If you really care about this problem, which is nice, try to get
> logrotate fixed.

Would you mind explaining how to go about that?

Florian


-- 
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/20101211010127.ge3...@florz.florz.dyndns.org

Feliz Año 2011..!!!

[Vigo Cans]

Hola!!!

Muchas Bendiciones para ti y tu familia, deseo invitarte a "Bendita la
lluvia" es una comunidad privada cuya actividad se realiza exclusivamente a
través de Internet. Es nació como iniciativa de un grupo de líderes de
diferentes países y continentes, que tienen amplia experiencia en programas
de dones y que tienen un gran compromiso de trabajar activamente hacia el
bienestar de todos.

Con el fin de ser parte de la lluvia bendita, una invitación directa de un
miembro activo es necesario.

Participación en lluvia bendita es totalmente voluntario y exclusivo para
las personas que son mayores de edad y que se compromete a cumplir con los
términos y condiciones necesarias para el desarrollo de nuestra actividad.

El uso de nuestro portal es gratuito y exclusivo para miembros activos.
También ponemos a su disposición una plataforma para participar en la
actividad más importante: "Da lo que puede recibir". Hemos desarrollado el
"ABUNDANCIA FÓRMULA" donde todos pueden beneficiarse del trabajo en equipo y
que todos tenemos las mismas oportunidades.

Registrate,  es solo por invitacion, para tomar la mejor posicion el codigo
de acceso es: 2537763



Sponsor: victorcabral
http://www.blessed-rain.org



Blessed Rain is a private community whose activity is done exclusively via
the internet. It's born as the initiative of a group of leaders from
different countries and continents, who have ample experience in gifting
programs and who have a huge commitment to actively work towards the
wellness of all.

In order to be a part of Blessed Rain, a direct invitation from an active
member is necessary.

Participation in Blessed Rain is totally voluntary and exclusive for persons
who are of legal age and who agree to comply with the terms and conditions
needed for the development of our activity.

The use of our portal is free and exclusive to active members. We also put
at your disposal a platform to participate in the most important activity:
"Give so that you may receive". We have developed the "ABUNDANCE FORMULA"
where all of us may benefit from teamwork and where all of us have the same
opportunities

Register, is only by invitation, for the best position to take the access
code is: 2537763



Sponsor: victorcabral
http://www.blessed-rain.org

-- 

-
18.5% por 6 dias
http://futuretrails.com/?ref=inversores
mas de 410 dias y
12.6% por 10 dias.
http://www.Plexfund.com/?ref=inversores
mas de 180 dias





 

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Florian Zumbiehl]

Hi,

> [...]
> > 
> > These lines from this package's maintainer scripts suggest that it likely
> > is affected by the vulnerability:
> > 
> > ---
> > chmod 640 $FRESHCLAMLOGFILE
> > chown "$dbowner":adm $FRESHCLAMLOGFILE
> > ---
> > 
> 
> What is wrong about these two lines? And even from ...

I'm not sure anything is wrong about those (though they very well may
be dangerous as well, that depends on the permissions of the directory
that file is in--namely, whether an unprivileged user can create entries
in it). The point of mentioning them was to make transparent why I think
your package likely is affected by logrotate's vulnerability.

Looking at it now, this package may actually be a false positive,
assuming that the directory is writable by root only?!

> [...]
> 
> > For some further details please see my announcement of this mass
> > filing on debian-qa:
> > 
> > http://lists.debian.org/debian-qa/2010/11/msg00024.html
> > 
> [...]
> 
> ... I don't quite understand why this would be problem specific to one of the
> packages you did the MBF for. If I get the idea of your exploit right, you

It's not specific. It's just that logrotate as a matter of fact doesn't get
fixed even though that would be the sane way to go about it.

> replace the log file by a symlink to a root-owned file, and in some mysterious
> way you then seem to be able to overwrite the root-owned file. Well, it will
> suffice for the evil person to be in adm group, you don't need to be $package
> user for doing that.

Well, in a rather non-mysterious way, that's what logrotate does, yes.

> But ok, you don't even claim there's a specific bug in our package, it's all
> logrotate's fault. Assuming clamav uses logrotate in a sane way (I wouldn't no
> of anyone claiming it does not), what should we do? Drop log rotation? Cool,
> thanks, then the security-tagged bug report against clamav is actually 
> justified
> because it'll soon fill up your disk, possibly resulting in a DoS. Come up 
> with
> it's own cron-job for log rotation? No, thank you.

I don't suggest any fixes (beyond fixing logrotate, which as a matter of
fact does not happen though). I just wanted to make maintainers aware that
their packages as a matter of fact are vulnerable because I assumed that
some maintainers would not necessarily like the idea of their packages
being vulnerable.

> At present, the only thing I'd plan to do is to either reassign this bug to
> logrotate or simply close it.

That's up to you, obviously (well, and in this particular case, assuming
it's a false positive, closing it may actually be the only sensible thing to
do ;-).

Florian


-- 
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/20101211014801.gg3...@florz.florz.dyndns.org

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Florian Zumbiehl]

Hi,

> On Fri, Dec 10, 2010 at 9:43 AM, Michael Tautschnig  wrote:
> >> These lines from this package's maintainer scripts suggest that it likely
> >> is affected by the vulnerability:
> >>
> >> ---
> >> chmod 640 $FRESHCLAMLOGFILE
> >> chown "$dbowner":adm $FRESHCLAMLOGFILE
> >> ---
> >>
> >
> > What is wrong about these two lines? And even from ...
> 
> It suggests the daemon itself creates the file. Copytruncate suggests
> logrotate also creates the file.

As noted in my reply to this mail, in this specific case it actually
doesn't (it's just the file, not the directory)--but generally, that was
the point, yes.

> Logrotate runs as root, so if the attacker (running as daemon user)
> creates the symlink, logrotate might overwrite an arbitrary file (I
> guess).

Essentially, that's it, or at least close to it. As already mentioned,
I don't recall all the details anymore, but my proof of concept somehow
used a hardlink to /etc/shadow that was made daemon-user-writable by
logrotate, thus allowing the daemon user to change the root password.
Or something. Also, almost certainly this vulnerability does not
depend on copytruncate.

Florian


-- 
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/20101211020152.gh3...@florz.florz.dyndns.org

Re: apt-diff: a tool to diff filesystem content against APT

[Osamu Aoki]

HI,

On Fri, Dec 10, 2010 at 12:02:44PM -0800, Tristan Schmelcher wrote:
> On Thu, Dec 9, 2010 at 11:12 PM, Goswin von Brederlow  
> wrote:
> > Osamu Aoki  writes:
> >
> >> On Fri, Dec 10, 2010 at 12:06:45AM +0900, Osamu Aoki wrote:
> >>> Hi,
> >>>
> >>> On Wed, Dec 08, 2010 at 12:52:28PM -0800, Tristan Schmelcher wrote:
> >>> > On Tue, Dec 7, 2010 at 11:30 PM, Goswin von Brederlow 
> >>> >  wrote:
> >>> > > Tristan Schmelcher  writes:
> >>> > >>> how does it deal with configurations generated in postinstall?
> >>> > I find debsums to be too basic for my needs. apt-diff is my attempt to
> >>> > improve upon it. I often want to answer the question "how does package
> >>> > X on my machine compare to a pristine installation?" debsums only
> >>> > gives part of the answer. It can't check files that are missing
> >>> > md5sums (which includes a lot of conffiles)
> >>                                      ~
> >>> Wrong.
> >>
> >> OOps..  I now see your point.  Sorry.
> >>
> >>> If you configure debsum correctly following manpage, md5sums are
> >>> available for all packages.  Use -g option to initialize it and make
> >>> sure to set the debconf boolean value debsums/apt-autogen to be "true".
> >>> I understand that this is an exra hussle.
> >>
> >> This is talking about files missing md5sums due to packaging practice of
> >> the maintainer.  conffiles are not debsums interest.
> >
> > Does debsums support ucf? Can it support ucf?

For most package, debsums generated /var/lib/dpkg/info/*md5sums files do
not have files under /etc.  I guess this comes from dh_md5sums default
behavior.

On my system, only following ships such data.
$ cd /var/lib/dpkg/info; grep " etc" *.md5sums |cut -d : -f 1|sort|uniq
bsdmainutils.md5sums
dput.md5sums
initscripts.md5sums
menu.md5sums
ppp.md5sums
runit.md5sums
sysv-rc.md5sums
ucf.md5sums

For me it is more of mistery why these have md5sums files.

bsdmainutils uses denhelper dh_md5sums without -x option.  I do not
understand.

dput does not use debhelper and manually creates it in debian/rules.  I
see why.

...

> > What I mean is that often generated conffiles are installed with ucf and
> > ucf keeps track of the original generated checksum and the possibly
> > localy modified file and such. Does/could debsums tap into that info to
> > find generated conffiles that were changed?
> 
> It would be pretty easy to tap into--the md5sums are all in
> /var/lib/ucf/hashfile and it's already in the format used by md5sum
> -c. But that still leaves a lot to be desired. On my machine there are
> only 26 entries in that file, whereas there are 1663 conffiles without
> md5sums.*

I agree the same observation. See  above on dh_md5sums.

> As far as I know there's no metadata available to check the
> integrity of those files--they have to be compared to the original
> files in the .deb as apt-diff does.

As I read manpage of dh_md5sums, it states:
   -x, --include-conffiles
   Include conffiles in the md5sums list. Note that this
information is redundant since it is included elsewhere in debian
packages.

I have no idea what this is.

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/20101211022343.ga...@debian.org

Re: apt-diff: a tool to diff filesystem content against APT

[Russ Allbery]

Osamu Aoki  writes:

> As I read manpage of dh_md5sums, it states:
>-x, --include-conffiles
>Include conffiles in the md5sums list. Note that this
> information is redundant since it is included elsewhere in debian
> packages.

> I have no idea what this is.

The *.conffiles files in /var/lib/dpkg/info have the checksums of all the
conffiles.  See also dpkg-query -f '${Conffiles}' -W .

-- 
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/87mxod58kp@windlord.stanford.edu

Re: apt-diff: a tool to diff filesystem content against APT

[Peter Samuelson]

[Osamu Aoki]
> As I read manpage of dh_md5sums, it states:
>-x, --include-conffiles
>Include conffiles in the md5sums list. Note that this
> information is redundant since it is included elsewhere in debian
> packages.

"Note that this information is redundant" - that's rich.  As though
the entire md5sums file weren't redundant.  (I.e., could easily be
generated at unpack time.)  People seem to hold on to their reasons
why it's important to have these integrity checks in the .deb itself,
not just on the installed system, but ... yeah.  Shipping md5sums of
conffiles is only a little bit more redundant than shipping md5sums
of the rest of the files.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20101211043002.gc13...@p12n.org