Re: RPM targets
Perhaps the tack to sail on this component is not "make rpm" but "make package", where a number of files is converted to a ~.spec, prototype/pkginfo, ~.cmpnt/~.pkg/~.prod, or whatever: 1) list of files (source -> target) 2) inittab mods 3) rc.d mods 4) copywrite (with shorthand for current GPL, MPL, etc) 5) meta info: html webtree, author email, bugreport email 6) meta: requires package, conflicts with package >From this, the relevant portions can be used to create the packaging files, from which a package can be built. This is more generic, but may require something like "libtool", except "pkgtool". Allan Hans Ulrich Niedermann wrote: > > Hi all, > > sorry to be replying to my own message, but I don't want to take > credit for other people's ideas. > > Hans Ulrich Niedermann <[EMAIL PROTECTED]> writes: > > > Michael Bletzinger <[EMAIL PROTECTED]> writes: > > > > > Is anyone working on creating rpm targets similar to "make dist". I was > > > thinking that automake could for example generate the spec file from a > > > template. > > > > I've implemented "make rpm" in my experimental automake-based > > package called "xtestsuite". It was more intended for myself to > > somehow get into the the automake/autoconf thing so the C/C++ sources > > are not very interesting. > > Waking up, I just remembered the software which gave me the idea > to try it: At least some older (1.9.something) Samba releases also > contained a "make rpm" function. But as Samba is rather a big project, > it seemed too complicated to me at that that time to learn about > Makefiles in general, automake/autoconf in special and RPM packaging > from it at the same time. > > Perhaps I should have a look at samba again now - I'd suspect their > rpm target is slightly more sophisticated than mine :-) Yet I don't > know why they seem to have abandoned it - they seemed to have done so > in the 2.0.[123] releases, if I remember correctly. > > Cheers, > > Uli
Re: rpcgen support for automake
Alexandre Oliva wrote: > On May 29, 2000, Marek Kowal <[EMAIL PROTECTED]> wrote: > > > I have an .x file and want to create, using rpcgen, stub files in > > automake. Later on I want to compile and link part of them into server, > > and the other part into client. Did anybody excercised this already? > > Add .x to SUFFIXES, the write rules to generate the .c files from .x. > Since you want to generate at least 2 files from the same .x, you > won't be able to use implicit rules (such as `.c.x:'). rpcgen usually has the command-line options for generating single individual files -- rpcgen -[cmlh] , but it generates them to stdout. I usually use: %_rpc.h: %_rpc.x $(RPCGEN) -h $< > $@ %_rpc_xdr.c: %_rpc.x $(RPCGEN) -c $< > $@ %_rpc_svc.c: %_rpc.x $(RPCGEN) -m $< > $@ %_rpc_clnt.c: %_rpc.x $(RPCGEN) -l $< | awk -f $(LIB)/rpcclnt.awk > $@ By convention, my XDR file or "interface" file is _rpc.x. (rpcclnt.awk is a filter to typecast the RPC calls, removing the compiler warnings) Allan
Re: ##-xxx-xxx.patch
Akim, everyone; Is there I way I can simply get the discussion, without the binary/patch traffic? I would prefer to receive this kind of thing through an update from a source-control (ie CVS) than copies from email. Should I sign up on a different list? Should [EMAIL PROTECTED] be formed? Allan
Re: Spam (was: »ç¹«¿ë°¡±¸ Á¾ÇÕ¼îÇθôÀÔ´Ï´Ù.)
One alternative is to go to whatever egroup.com is now. Egroup grew from bigfoot or something, it's a list-server that requires that all posters are members of the list. Invites may be required. Or... GNU could extend their mailinglists to require authentication on their website and membership in the list before you can post. FYC Allan John Poltorak wrote: > > On Wed, Mar 07, 2001 at 06:36:54PM +0900, DZ>F0!18 wrote: > > Can someone stop this spam getting in here? > > -- > John
Re: Automake release
> As I recall, a long time ago the Gnits group decided that we simply > wouldn't support more than 2 release numbers. If the current release > is 1.4, then the next one is 1.5. Unfortunately for us, I didn't want > to do this with automake since I've been saying for a long time "1.5 > will do this", "1.5 will do that". Bleah, my bad. > > The fork identifier stuff is just so that people who make their own > version of automake, which happens depressingly often, can somehow > mark it without intefering with a Makefile.am where a version number > is in AUTOMAKE_OPTIONS. > > In all this is an ugly situation. I'm thinking of hacking automake to > recognize that `1.4-p' is between 1.4 and 1.5 (so that > AUTOMAKE_OPTIONS=1.4-p1 will work ok when 1.5 is used). So whatever happened to numeric point releases? "1.5 will do that" "this is release 1.4.3, automake-1.4.3" Those who make one-offs can adapt. Allan
Re: coexist multiple versions of automake
Paul Lew wrote:
> I would like to propose we modify automake (and autoconf) to allow
> multiple versions of automake coexisting on a given system. In our
> work, we used various open source libraries and each one of them work
> with a particular version of automake. This makes it hard for us to
> upgrade. If automake can be specified as automake-1.4 and
> automake-1.6 like what tcl did in the past, this will make people's
> life a lot easier.
When you say "libraries", are you referring to libXXX.{a,so}, or "The
ABC Corp Widget Library" (a collection of libraries and non-standard
tools)?
Typically, changes in toolkits that cause huge inconsistencies are given
different major version numbers, but automake will probably be 1.X
forever.
Segmenting automake into automake-1.4/1.5/1.6 might be OK so long as
users have the choice of choosing "automake-X.y", or simply choosing
"automake" (which would continue to be the latest automake major
revision). I for one like to install automake, and know that when my
check for updates yields "nothing new", my automake is the latest.
> Since I am not familiar with the inner work of automake, for the
> already released versions, how hard will it be to patch them to allow
> for this? I would really like to have 2 libraries using different
> version of automake to work together.
Did you consider getting the libraries updated? Yeah, you probably did.
This *is* an automake issue, and not a libtool issue, right?
Allan
Re: InterScan NT Alert (bogus)
Hey everyone; Off-topic, but I'm the [EMAIL PROTECTED] and I didn't generate this posting. > Received: from fencepost.gnu.org ([EMAIL PROTECTED] >[199.232.76.164]) > by chickenandporn.com (8.12.3/8.12.3/Debian -4) with ESMTP id g3LKi2kb004799 > for <[EMAIL PROTECTED]>; Sun, 21 Apr 2002 16:44:04 -0400 > Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) > by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) > id 16zO9x-00086q-00; Sun, 21 Apr 2002 16:42:09 -0400 > Received: from igate2.chron.com ([130.80.28.26] helo=fwall2.chron.com) > by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) > id 16zO9V-000848-00 > for <[EMAIL PROTECTED]>; Sun, 21 Apr 2002 16:41:41 -0400 > Received: from nttrend ([130.80.30.72]) by fwall2.chron.com > (Netscape Messaging Server 3.6) with SMTP id AAA548B > for <[EMAIL PROTECTED]>; Sun, 21 Apr 2002 15:41:39 -0500 > From: [EMAIL PROTECTED] Apparently, fwall2.chorn.com sent this. ...and my postings to [EMAIL PROTECTED] don't come through C&P with an address from there... and the RR doesn't resolve back as C&P. Obviously, someone's making this stuff up, but I don't get why. Just so you know... this is spam to say that the original spam didn't come from me. Why are we still allowing posts from addresses that aren't on this list? Allan Clark [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: > > Sender, InterScan has detected virus(es) in your e-mail attachment. > > Date: Sun, 21 Apr 2002 15:46:40 -0500 (Central Daylight Time) > Method: Mail > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > File: height.pif > Action: deleted > Virus: WORM_KLEZ.G
Re: Configure tool/cvs repository trouble
Patrick Guio wrote: > If I just "touch configure" then everything is running ok again. I am not > sure which of the package is generating this trouble nut is there any > policy/strategy of using configuration tool together with a cvs > repository? A common timestamp issue is introduced when developers check in generated content such as configure, Makefile.in, Makefile, config.h.in, etc. CVS seems to alter timestamps on some files in an order that conflicts with automake and autoconf. Checking in generated content should be avoided where possible. The only reason I've heard for people to put generated content into CVS is for downstream developers; If the downstream doesn't have all the same auto* tools installed, make a drop with "make dist" instead. I'm not saying that this is your problem or the sole issue; I'm saying this to confirm that you're not walking into pain and suffering. Others here may (will?) disagree. Allan
Re: Security vulnerability in automake
This is really not an issue; standard users cannot overwrite /etc/passwd
You don't compile/install unknown software as root, do you? If so, then
my configure file says this:
date > /etc/passwd
Sure, this could be replaced with a hashed random name, but the same
vulnerability remains. Don't build as root?
Allan
Lawrence Teo wrote:
> I was learning Automake last night, and I think I found a security
> vulnerability. I'm not sure if this is already known, but I couldn't
> find it on Bugtraq. The security vulnerability is the insecure
> creation of temporary files in the config.guess script which leads
> to a race condition.
>
> In the config.guess script, there's a line that says:
>
> dummy=dummy-$$
>
> And further down...
>
> echo "int dummy(){}" > $dummy.c ;
>
> An attacker can create a number of symbolic links called
> dummy-PID.c pointing to important files like /etc/passwd. PID in
> this case would be the attacker's guesses on what the PID of the
> config.guess script will run as. If root runs ./configure in a
> source tree containing these malicious symlinks, and if the
> configure script in turn runs config.guess, the /etc/passwd file
> may potentially be overwritten with "int dummy(){}", resulting in
> a denial of service attack.
Re: Security vulnerability in automake
Effort to reduce this kind of a security "hole" are quite fruitless, so long as I or anyone can build a ./configure that will simply "rm -fr /*"; nevertheless, I do support David's comment: > 2. A non-root mindset should be encouraged. Indeed, I'd support a case > for a default of "if root then abandon build", but with an override > capability for those (probably few) packages where root may be desirable > or even essential. > Reinforcing this kind of a change in behavior may or may not be within our rights or objectives. It's a personal objective of mine, which I admit may be a soapbox upon which I stand alone. Allan David Lee wrote: > On Sat, 8 Jun 2002, Bernd Jendrissek wrote: > > > On Fri, Jun 07, 2002 at 04:50:23PM -0400, Lawrence Teo wrote: > > > My point is, if config.guess can be hardened against such potential symlink > > > attacks, why shouldn't it be? Of course, it would be great to educate all > > > admins not to build stuff as root. But it would also be a responsible thing > > > to fix config.guess if we know that there's a potential issue in there. > > > > [snip] > > > > > Likewise, having a "hardened" config.guess file would not necessarily > > > prevent symlink attacks, but it'll definitely make it much harder for an > > > attacker to exploit it, even if the admin is sloppy. > > > > An attacker is hardly likely to distribute a "hardened" config.guess > > > > Build untrusted packages as root. Hose your system. Repeat until lesson > > is learned: do not built untrusted packages as root. > > There seems to be a flaw there: assuming that the attacker is the > distributor/provider of the package containing "config.guess". > > But the attacker may well be a third party, exploiting a weakness in the > victim/builder's system as a weak, but innocent, package is installed. > > If there is a weakness in "config.guess" (or anywhere else) that can be > reasonably fixed, shouldn't it be fixed? > > All those of us with experience would agree that, ideally, package > building ought to be non-root. But I can think of at least one bona fide, > trustworthy package, Samba, that, on some platforms, can benefit from > being built as root as autoconf tries to discover something at root level > (from foggy memory, I seem to recall it was a runtime locking mechanism). > > > Summary: > > 1. Attacker and package-provider may well be different parties; > > 1. If there is a weakness, root or otherwise, reasonable attempts should > be made to fix it, regardless of other considerations; > > 2. A non-root mindset should be encouraged. Indeed, I'd support a case > for a default of "if root then abandon build", but with an override > capability for those (probably few) packages where root may be desirable > or even essential. > > -- > > : David LeeI.T. Service : > : Systems Programmer Computer Centre : > : University of Durham : > : http://www.dur.ac.uk/t.d.lee/South Road: > : Durham: > : Phone: +44 191 374 2882 U.K. :
Re: Security vulnerability in automake (understood, agreed)
Lawrence; I see that the key here is that the attacker is a user with local access to a system (be it by login, security hole in another binary giving shell access as that binary's user, etc). The admin merely runs the innocent package, and due to the attacker's symlinks, causes damage to his own system. OK, it can then occur more often than a "trojan horse ./configure" like my "rm -fr /" comment. Understood, and I agree that it's worth protecting. Thanks for clarifying. Allan Lawrence Teo wrote: > >Effort to reduce this kind of a security "hole" are quite fruitless, so > >long as I > >or anyone can build a ./configure that will simply "rm -fr /*"; > > Please correct me if I'm wrong, but doesn't that again inaccurately assume > what David pointed out: that the attacker and distributor/provider are the > same person? If the attacker is not the provider, then there's no way for > the attacker to get a user to run a configure with "rm -rf /". Yet, if > config.guess still contains that "hole", then an attacker can still cause > some damage. > > Maybe I should explain my attack again. Attacker sets up symlinks in /tmp > like this: > > attacker$ cd /tmp > attacker$ mkdir package-1.0.0 > attacker$ cd package-1.0.0 > attacker$ ln -s /etc/passwd dummy-7836.c > attacker$ ln -s /etc/passwd dummy-7837.c > attacker$ ln -s /etc/passwd dummy-7838.c > [] > > Now, the admin downloads package-1.0.0.tar.gz in its original, untampered > form. Attacker has no way to modify package-1.0.0.tar.gz. But > package-1.0.0.tar.gz contains the config.guess "hole". Admin builds and > installs it as follows: > > admin$ su - > root# cd /tmp > root# tar zxvf package-1.0.0.tar.gz > root# cd package-1.0.0 > root# ./configure > root# make > root# make install > > Since configure calls config.guess, which in turn overwrites the dummy-$$.c > file (if config.guess happens to run as the attacker's predicted PID), > /etc/passwd is hosed. All this while, attacker does not need to modify > package-1.0.0.tar.gz to introduce malicious scripts. > > This is just one way to perform an attack, and there may be others. I do > know that Slackware's build scripts use the /tmp directory for building as > root, so it may be vulnerable to this attack. > > Lawrence > > -- > Lawrence Teo > lcteo at uncc dot edu > http://www.coe.uncc.edu/~lcteo > > _ > Join the worlds largest e-mail service with MSN Hotmail. > http://www.hotmail.com
