Re: follow-up on backdoor CPU usage (was: libsystemd dependencies)

[Jacob Bachmeyer]

Jacob Bachmeyer wrote:
[...]  The preliminary reports that it was an RCE backdoor that would 
pass commands smuggled in public key material in SSH certificates to 
system(3) (as root of course, since that is sshd's context at that 
stage) are inconsistent with the slowdown that caused the backdoor to 
be discovered.  I doubt that SSH logins were using that code path, and 
the SSH scanning botnets almost certainly are not presenting 
certificates, yet it apparently (reports have been unclear on this 
point) was the botnet scanning traffic that led to the discovery of 
sshd wasting considerable CPU time in liblzma...


I am waiting for the proverbial other shoe to drop on that one.


I have been given 
(https://www.openwall.com/lists/oss-security/2024/04/18/1>) a 
satisfactory explanation for the inconsistency:  OpenSSH sshd uses 
exec(2) to reshuffle ASLR before accepting each connection, and the 
backdoor blob's tampering with the dynamic linking process greatly 
reduces the efficiency of ld.so on top of its own processing.  The 
observable wasted CPU time was the backdoor's excessively-complex 
initialization, rather than any direct effect on sshd connection processing.



-- Jacob

Re: Minimal example for understanding the usage of TESTS in Makefile.am

[Simon Richter]

Hi,

On 01.08.2013 00:46, Peng Yu wrote:

> I'm not able to understand the usage of TESTS in Makefile.am, as there
> are many other things discussed in conjunction with TESTS and which
> obscures the description of TESTS. Could anybody point me a minimal
> example (without any things unrelated to TESTS) that demonstrates the
> usage of TESTS? Thanks.

While not an example, it can be simplified to:

When 'make check' is run, each file listed in TESTS is executed in turn,
and if the return code is non-zero, this is flagged as an error.

Depending on your project, these files can be either scripts that invoke
a program from your project and verifies its behaviour, or programs that
are specially built, if you want to test a library.

If you write

TESTS = foo bar

then 'make check' will invoke

,/foo

followed by

./bar

How "foo" and "bar" are built is completely independent, for a program
you could use

check_PROGRAMS = foo bar

foo_SOURCES = foo.c
bar_SOURCES = bar.c

The "check_" tells automake to build these programs only before running
the tests.

   Simon

Minimal example for understanding the usage of TESTS in Makefile.am

[Peng Yu]

Hi,

I'm not able to understand the usage of TESTS in Makefile.am, as there
are many other things discussed in conjunction with TESTS and which
obscures the description of TESTS. Could anybody point me a minimal
example (without any things unrelated to TESTS) that demonstrates the
usage of TESTS? Thanks.

-- 
Regards,
Peng

GNU Mach's usage of the Auto* tools (was: [OT] avoid long ac_user_opts line in configure)

[Thomas Schwinge]

[Moved to the  and  mailing lists.]


Hello!

On Thu, Jan 11, 2007 at 12:17:25AM +0100, Ralf Wildenhues wrote:
> * Thomas Schwinge wrote on Wed, Jan 10, 2007 at 09:40:41PM CET:
> > #v+
> > $ ~/tmp/source/gnumach/clean/gnumach-1-branch/configure --help | egrep ^\ \ 
> > --...\?able- | wc -l
> > 102
> > #v-
> 
> Hehe.  To add some on-topicness to this size comparison: how long was
> the generated line in the configure script?

I don't have such a line, because I'm using automake 1.10, I guess.  If
you are really interested I could try with another version.


> Does gnumach exercise autotools thoroughly and is large in some way(s)?

Yes and yes, I'd say.  And in fact I had the idea of presenting what I
recently have done (converting GNU Mach to use Automake) on these very
mailing lists, but didn't get to actually do that so far.


> Can I build it on a GNU/Linux system without many prerequisites?

Yes.  If you're using Debian you need to install the `mig' package, if
not, that's easily doable by hand.


> I'm interested in adding it to my list of irregularly exercised
> autotools regression suite.

Nice!  So, you actually ask me to present it here.  :-)

You can basically follow the instructions from
.  You're most
probably interested in using the cvs sources, the `gnumach-1-branch'.
You could supply `--disable-default-device-drivers' to the `configure'
command line to avoid compiling all the device drivers into the kernel
image, which slows down the build, but -- most probably -- won't give any
new results for your use case.  Everything else (build system wise)
should work as expected.


Please ask, if there are questions.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: AM_CFLAGS usage

[Ralf Wildenhues]

Hello Norbert,

* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 06:42:15PM CEST:
> 
> Ehm, where do I find the documentation to config.site?

Oh, sorry, I forgot to mention that config.site is an Autoconf feature.
Its manual has the information.  (The current manual isn't online, but
let's hope that changes next week...)

Cheers,
Ralf

Re: AM_CFLAGS usage

[Norbert Sendetzky]

On Monday 12 June 2006 12:53, Ralf Wildenhues wrote:
>   : ${CFLAGS='-Wall -ansi -pedantic'}
>
> before AC_PROG_CC in configure.ac.  Users with non-GCC compilers won't
> like you because they will have to set CFLAGS to override this, and
> users (with any kind of compiler) won't like you because you take away
> the default (set -g if possible, add -O2 if possible) setting they

OK, not the best option ;-)

> FWIW, I prefer that packages don't override CFLAGS at all.  For specific
> settings, I keep a long-term build tree with a working config.status
> file (and of course a config.cache as well) around.  Or a config.site
> file (if you don't know what this is, read up on it in the Autoconf
> manual).

Ehm, where do I find the documentation to config.site? I couldn't find it in 
the automake manual
http://sources.redhat.com/automake/automake.html

and in the autobook is only a short notice about this
http://sources.redhat.com/autobook/autobook/autobook_281.html

Google does also not reveal any useful information on the first pages.


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpYjcZMRwCrQ.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Wildenhues]

* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 11:06:36AM CEST:
> On Monday 12 June 2006 10:28, Ralf Corsepius wrote:
> > > > Note though that
> > > >   -Wall -ansi -pedantic
> > > >
> > > > is pretty GCC specific, and will make many other compilers barf
> > > > heavily.  So if your package targets portability, it'd be nice
> > > > to allow your users to override these flags (preferably by
> > > > ./configure CFLAGS='...').
> > >
> > > How can I do this?
> >
> > NOTE: CFLAGS !!

> Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him 
> correctly.

Yes.  Maybe this should be in a FAQ or so:  you can put
  : ${CFLAGS='-Wall -ansi -pedantic'}

before AC_PROG_CC in configure.ac.  Users with non-GCC compilers won't
like you because they will have to set CFLAGS to override this, and
users (with any kind of compiler) won't like you because you take away
the default (set -g if possible, add -O2 if possible) setting they
expect from packages using Autoconf.  (I first through of
http://lists.gnu.org/archive/html/automake/2005-09/msg00108.html but
that tackles a slightly different problem setting.)

FWIW, I prefer that packages don't override CFLAGS at all.  For specific
settings, I keep a long-term build tree with a working config.status
file (and of course a config.cache as well) around.  Or a config.site
file (if you don't know what this is, read up on it in the Autoconf
manual).

Cheers,
Ralf

Re: AM_CFLAGS usage

[Norbert Sendetzky]

On Monday 12 June 2006 10:28, Ralf Corsepius wrote:
> > > Note though that
> > >   -Wall -ansi -pedantic
> > >
> > > is pretty GCC specific, and will make many other compilers barf
> > > heavily.  So if your package targets portability, it'd be nice
> > > to allow your users to override these flags (preferably by
> > > ./configure CFLAGS='...').
> >
> > How can I do this?
>
> NOTE: CFLAGS !!
>
> Not using AM_CFLAGS=-Wall -ansi -pedantic
>
> and
> ./configure CFLAGS="-Wall -ansi -pedantic"
>
> is what Ralf W. is referring to.

Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him 
correctly. If rewrite my files to support only

./configure CFLAGS="-Wall -ansi -pedantic"

these flags are never set by default if only ./configure is called.


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgp5924OffuBx.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Corsepius]

On Mon, 2006-06-12 at 10:16 +0200, Norbert Sendetzky wrote:
> Hi Ralf
> 
> > > Norbert Sendetzky wrote:
> > > > This works, but as soon as I move AM_CFLAGS to the Makefile.am in the
> > > > parent directory, they aren't set any more. Is this the way it was
> > > > intended and the only way to set them globally is to AC_SUBST them or
> > > > is there something wrong in my files?
> >
> > Besides the information Marc already gave you, what's wrong with
> > globally setting it by AC_SUBSTing?  You can still override it per
> > Makefile.am.
> >
> > Note though that
> >   -Wall -ansi -pedantic
> >
> > is pretty GCC specific, and will make many other compilers barf
> > heavily.  So if your package targets portability, it'd be nice
> > to allow your users to override these flags (preferably by
> > ./configure CFLAGS='...').
> 
> How can I do this?

NOTE: CFLAGS !!

Not using AM_CFLAGS=-Wall -ansi -pedantic

and 
./configure CFLAGS="-Wall -ansi -pedantic"

is what Ralf W. is referring to.

> According to the docs, AM_CFLAGS will be overwritten by package specific 
> flags 
> but not by flags provided by the user.
Nope. CFLAGS and AM_CFLAGS are being concatenated inside of a Makefile
using AM_CFLAGS.

Ralf

Re: AM_CFLAGS usage

[Norbert Sendetzky]

Hi Ralf

> > Norbert Sendetzky wrote:
> > > This works, but as soon as I move AM_CFLAGS to the Makefile.am in the
> > > parent directory, they aren't set any more. Is this the way it was
> > > intended and the only way to set them globally is to AC_SUBST them or
> > > is there something wrong in my files?
>
> Besides the information Marc already gave you, what's wrong with
> globally setting it by AC_SUBSTing?  You can still override it per
> Makefile.am.
>
> Note though that
>   -Wall -ansi -pedantic
>
> is pretty GCC specific, and will make many other compilers barf
> heavily.  So if your package targets portability, it'd be nice
> to allow your users to override these flags (preferably by
> ./configure CFLAGS='...').

How can I do this?
According to the docs, AM_CFLAGS will be overwritten by package specific flags 
but not by flags provided by the user.

Thanks


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpL8sGQvKzJd.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Wildenhues]

Hello Norbert, Marc,

> Norbert Sendetzky wrote:
> >
> > This works, but as soon as I move AM_CFLAGS to the Makefile.am in the 
> > parent 
> > directory, they aren't set any more. Is this the way it was intended and 
> > the 
> > only way to set them globally is to AC_SUBST them or is there something 
> > wrong 
> > in my files?

Besides the information Marc already gave you, what's wrong with
globally setting it by AC_SUBSTing?  You can still override it per
Makefile.am.

Note though that
  -Wall -ansi -pedantic

is pretty GCC specific, and will make many other compilers barf
heavily.  So if your package targets portability, it'd be nice
to allow your users to override these flags (preferably by
./configure CFLAGS='...').

Cheers,
Ralf

Re: AM_CFLAGS usage

[Marc Alff]

Hi


Norbert Sendetzky wrote:
> Hi all
>
> I've tried to set the C flags for my package globally and used AM_CLFAGS for 
> this. Unfortunately AM_CLFAGS is only honored if it is defined in the same 
> Makefile.am.
>
> AM_CFLAGS = -Wall -ansi -pedantic
> pkglib_LTLIBRARIES = libmysqlbackend.la
> libmysqlbackend_la_SOURCES = mysqlbackend.c
> libmysqlbackend_la_CFLAGS = $(AM_CFLAGS)
>
> This works, but as soon as I move AM_CFLAGS to the Makefile.am in the parent 
> directory, they aren't set any more. Is this the way it was intended and the 
> only way to set them globally is to AC_SUBST them or is there something wrong 
> in my files?
>
>   
As far as I know, this is intended.

If you need to share common code in multiple Makefile.am within the same
project,
you can also try :

common.am :
(AM_CFLAGS goes here)

dir1/subdir2/Makefile.am :
include ../../common.am

Personally, I do things like this :

dir1/subdir2/Makefile.am :

include $(top_srcdir)/PreRules.am
(... content of Makefile.am goes here ...)
include $(top_srcdir)/PostRules.am

where PreRules.am contains among other things common compilation flags,
and PostRules contains common rules that depends on variables set (or
not) in the body of each Makefile.am

Hope this helps,
Marc Alff

AM_CFLAGS usage

[Norbert Sendetzky]

Hi all

I've tried to set the C flags for my package globally and used AM_CLFAGS for 
this. Unfortunately AM_CLFAGS is only honored if it is defined in the same 
Makefile.am.

AM_CFLAGS = -Wall -ansi -pedantic
pkglib_LTLIBRARIES = libmysqlbackend.la
libmysqlbackend_la_SOURCES = mysqlbackend.c
libmysqlbackend_la_CFLAGS = $(AM_CFLAGS)

This works, but as soon as I move AM_CFLAGS to the Makefile.am in the parent 
directory, they aren't set any more. Is this the way it was intended and the 
only way to set them globally is to AC_SUBST them or is there something wrong 
in my files?

Thanks for your help


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpT9rYZMha6u.pgp
Description: PGP signature

AM_CFLAGS usage

[Norbert Sendetzky]

Hi all

I've tried to set the C flags for my package globally and used AM_CLFAGS for 
this. Unfortunately AM_CLFAGS is only honored if it is defined in the same 
Makefile.am.

AM_CFLAGS = -Wall -ansi -pedantic
pkglib_LTLIBRARIES = libmysqlbackend.la
libmysqlbackend_la_SOURCES = mysqlbackend.c
libmysqlbackend_la_CFLAGS = $(AM_CFLAGS)

This works, but as soon as I move AM_CFLAGS to the Makefile.am in the parent 
directory, they aren't set any more. Is this the way it was intended and the 
only way to set them globally is to AC_SUBST them or is there something wrong 
in my files?

Thanks for your help


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpxkPTCwaabm.pgp
Description: PGP signature

Re: some usage questions

[Alexandre Duret-Lutz]

>>> "Martin" == Martin MAURER <[EMAIL PROTECTED]> writes:

[...]

 Martin> I thought about a noinst library, and this might be an option. 

It is.

 Martin> what i would like to have is a configure file in the
 Martin> toplevel directory, which then checks the dependencies
 Martin> for all the clients and enables building those clients,
 Martin> which can be built.

See `Conditional subdirectories' is the Automake manual.

 Martin> it would be nice if changes in sharedc++ would be
 Martin> discovered, when i try to rebuild (for example) the
 Martin> server thus rebuilding the sharedc++ code first.

The easiest way for this is to list sharedc++ first in SUBDIRS,
so it is always recursed first.  That way the library will
always be up to date when the client are built.

If you use xxx_LDADD = ../sharedc++/libwhatever.a when building
client xxx, the client will be relinked whenever libwhatever.a
has changed.
-- 
Alexandre Duret-Lutz

some usage questions

[Martin MAURER]

Hello all,

I am developing a project (http://fireflier.sf.net), which uses
automake. I don't know a lot about automake, and so far i didnt find
documentation, which helps me with my problem - so any pointers in the
correct direction will be appreciated.
fireflier is a interactive firewall system which is split into a server
and a client part.
So far i had no problems, but now as the project grows, i have to think
over my automake configs again.

My sourcecode layout is:
.../server
.../qtclient   
.../gnomeclient
.../shellclient
.../sharedc++/... - this is some code (mostly network code), that is
used by the server and all clients.

I dont want to make the sharedc++ directory a library, as the code is
fireflier specific, and installing this on systems wont be a good thing.
I thought about a noinst library, and this might be an option. Oppinions
?

what i would like to have is a configure file in the toplevel directory,
which then checks the dependencies for all the clients and enables
building those clients, which can be built.
it would be nice if changes in sharedc++ would be discovered, when i try
to rebuild (for example) the server thus rebuilding the sharedc++ code
first.

are there any good reasons not to handle the package that way ?
(especially during development this would be nice to have)
otherwise i would have to split all those parts into their own tar.gz
files and add sharedc++ everywhere - and as all my work is in subversion
(cvs replacement), this might get messy.

what i actually need, is some pointer on automake options how to achieve
this (if i am not completely wrong on my setup) 

greetings
Martin



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

Re: Usage

[Tom Tromey]

> "John" == John Darrington <[EMAIL PROTECTED]> writes:

John> One particular problem is the way in which they modify each other's
John> input files. After a while, your Makefile.am looks like this:

John> SUBDIRS= intl m4  intl m4  intl m4  intl m4  intl m4  intl m4
John> intl m4  intl m4

Report this as a bug against whatever tool (presumably gettext) is
modifying Makefile.am.

Tom

Usage

[John Darrington]

Recent versions of auto{make,conf} have become a pain to use.
Especially if you're using gettext too.

I think that some of these tools are trying to be just a little bit
too clever.

One particular problem is the way in which they modify each other's
input files. After a while, your Makefile.am looks like this:

SUBDIRS= intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4 
 intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4
  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m4  intl m
4  intl m4  intl m4  intl  intl m4 src intl po doc
EXTRA_DIST= config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath
 mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.r
path mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  conf
ig.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  
config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldi
rs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinsta
lldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath mki
nstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.rpath
 mkinstalldirs  config.rpath mkinstalldirs  config.rpath mkinstalldirs  config.r
path mkinstalldirs  config.rpath mkins




And your configure.ac has a similar problem at AC_OUTPUT

Also, I've never been able to ensure that po/Makefile gets its
Makevars included properly --- Sometimes it does, sometimes not.  If
not, then one has to delete everything and try autoconf; automake ;
gettextize --- in random order until things work again.

It really starts to waste a lot of time, which is a shame, because a
few years ago, these tools were really usefull.

automake usage

[Tom Tromey]

Today I wrote a dumb little script to estimate how often automake is
used.  The script searches a set of SRPM files for `configure.in' and
`Makefile.am' files, and generates a report showing how many packages
use autoconf and how many use automake.

Then I ran this script on all the SRPMs in Red Hat Linux 6.2 (the most
recent source CD I have conveniently lying around right now).

There were 503 packages.
Of these, 229 use autoconf (i.e., have a "configure.in" file --
error is likely to be small)
125 packages use automake (i.e., have a "Makefile.am" file)

So automake is in use by about 55% of all the packages using autoconf.
I wonder if that percentage has changed between 6.2 and now.

I don't know if this is interesting, but now we know it :-)

Tom