September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Elisp security checks? 26 years, 7 months

Karl M. Hegbloom

Would it be useful for XEmacs to warn if it finds lisp that is world or group writeable? It occured to me that a system cracker or prankster could subvert root's XEmacs, and install a cookie monster or something worse. What about a dump-time config option to set the group that should own the systemwide XEmacs lisp files, and if that group should have write access or not? I guess this feature might be an optional one too. Also the user's personal elisp in the home directory ought to be checked this way as well.

1 participants
0 comments

Re: [Failure] XEmacs 21.0 "Norwegian" configured for `alphaev56-dec-osf4.0d' 26 years, 7 months

SL Baur

I see one problem, probably not related to your report -- I forgot to rerun autoconf after applying Michael's AIX patch. I'll have to repackage the distribution, sigh. Kevin Oberman <oberman(a)es.net> writes in xemacs-beta(a)xemacs.org: > Actually, two failures! One when patching up and another when > installing from scratch. ... > checking the configuration name > Invalid configuration `alphaev56-dec-osf4.0d': machine `alphaev56-dec' not recognized I thought someone sent a patch to fix this. [...] 1998-07-23 Martin Buchholz <martin(a)xemacs.org> * configure.in: - support multiple flavors of alpha, (XEmacs treats them identically) > I gave a quick look at configure and I don't understand how this > happened. It looks right! Did a patch I had installed not make the > actual source even though I had it? > case "$canonical" in > sparc-*-* ) machine=sparc ;; > alpha*-*-* ) machine=alpha ;; That looks right. Martin's patch added the `*' right after the `alpha'. > and > case "$canonical" in > *-*-linux* ) opsys=linux ;; > *-*-netbsd* ) opsys=netbsd ;; > *-*-openbsd* ) opsys=openbsd ;; > *-*-nextstep* ) opsys=nextstep ;; > *-*-vms ) opsys=vms ;; > *-dec-osf1.3 | *-dec-osf2* ) opsys=decosf1-3 ;; > *-dec-osf1.2 | *-dec-osf1* ) opsys=decosf1-2 ;; > *-dec-osf3.[2-9] ) opsys=decosf3-2 ;; > *-dec-osf3* ) opsys=decosf3-1 ;; > *-dec-osf4* ) opsys=decosf4-0 ;; That wasn't changed. > Can someone better at shell see why this is happening and why didn't > it happen with the patched version? > Unfortunately I had to delete the patched version to have room for the > full one and can't compare the configure scripts. Due to steve braindamage, configure didn't change at all between pre12 and 21.0. Best recommendation is to run configure with `-x' and examine the resulting trace for clues as to how it is bombing.

1 participants
0 comments

Re: MIME attachments on NT in VM 26 years, 7 months

Darryl Okahata

Hrvoje Niksic <hniksic(a)srce.hr> wrote: > Peter Windle <peterw(a)ugsolutions.com> writes: > > > I think that somewhere not-very-far down the line, XEmacs is going > > to need support for reading (and possibly writing) arbitrary bits > > 'o' registry from elisp, though. I might take a look at this at some > > point in the (near) future.... > > Kirill planned to do this at some point. He wanted to use the > database mechanism for that, but I'm not sure how useful that would > be. It's probably a better idea to define functions like: Whatever happened to Kirill's database/registry patches? Way back, on Jan 10, he posted some patches that allowed access to the registry (they were in a file called "src/database-msw.c")? They never made it into the source tree. [ They're in my archives, and I can't tell if Kirill withdrew the patches or not, from the ensuing discussion between him, Hrvoje, and Steve. It appears that he wanted them applied, though. ] -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 participants
0 comments

Re: `elib' is missing from cvs.xemacs.org 26 years, 7 months

SL Baur

Karl M Hegbloom <karlheg(a)inetarena.com> writes in xemacs-beta(a)xemacs.org: > I did not see `elib' at cvs.xemacs.org in the xemacs-packages/libs > directory. Shouldn't it get added to accompany the new `pcl-cvs'? It will be added. The initial package kit to go with 21.0 is using the old pcl-cvs.

1 participants
0 comments

Fix for problem with configure on Digital UNIX 26 years, 7 months

Kevin Oberman

I found and fixed the problem. A patch missed the distribution. :-( I really should have caught it back when it was submitted back in May or June. Since my copy was patched, I never saw the problem until I did the fresh install of 21.0 "Norwegian". Here is the one character patch: *** config.sub.orig Thu Sep 10 17:11:12 1998 --- config.sub Thu Sep 10 17:06:44 1998 *************** *** 158,164 **** | sparc-* | ns32k-* | fx80-* | arm-* | c[123]* \ | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* | power-* \ | none-* | 580-* | cray2-* | h8300-* | i960-* | xmp-* | ymp-* \ ! | hppa1.0-* | hppa1.1-* | alpha-* | we32k-* | cydra-* | ns16k-* \ | pn-* | np1-* | xps100-* | clipper-* | orion-* | sparclite-* \ | pdp11-* | sh-* | powerpc-* | powerpcle-* | sparc64-* | mips64-* | mipsel-* \ | mips64el-* | mips64orion-* | mips64orionel-* | mab-*) --- 158,164 ---- | sparc-* | ns32k-* | fx80-* | arm-* | c[123]* \ | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* | power-* \ | none-* | 580-* | cray2-* | h8300-* | i960-* | xmp-* | ymp-* \ ! | hppa1.0-* | hppa1.1-* | alpha*-* | we32k-* | cydra-* | ns16k-* \ | pn-* | np1-* | xps100-* | clipper-* | orion-* | sparclite-* \ | pdp11-* | sh-* | powerpc-* | powerpcle-* | sparc64-* | mips64-* | mipsel-* \ | mips64el-* | mips64orion-* | mips64orionel-* | mab-*) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 participants
0 comments

[Failure] XEmacs 21.0 "Norwegian" configured for `alphaev56-dec-osf4.0d' 26 years, 7 months

Kevin Oberman

Actually, two failures! One when patching up and another when installing from scratch. Patched up from pre12. Configure and build went fine, but an attempt to list installed packages (Options->Customize->List Packages") failed with the messages: Loading package-ui... generating package customizations... Loading finder... Loading finder...done Wrong type argument: stringp, nil This worked fine with pre12, but only after installing the [URGENT PATCH]. When I patched from pre12 to "Norwegian", I got an error that the patches to package-get and packages-ui were already installed. Then I tried installation from scratch. Restored the xemacs-21.0 tar file and the info and elc files. > ./configure checking host system type... alphaev56-dec-osf4.0d checking whether ln -s works... yes checking the configuration name Invalid configuration `alphaev56-dec-osf4.0d': machine `alphaev56-dec' not recognized I gave a quick look at configure and I don't understand how this happened. It looks right! Did a patch I had installed not make the actual source even though I had it? case "$canonical" in sparc-*-* ) machine=sparc ;; alpha*-*-* ) machine=alpha ;; and case "$canonical" in *-*-linux* ) opsys=linux ;; *-*-netbsd* ) opsys=netbsd ;; *-*-openbsd* ) opsys=openbsd ;; *-*-nextstep* ) opsys=nextstep ;; *-*-vms ) opsys=vms ;; *-dec-osf1.3 | *-dec-osf2* ) opsys=decosf1-3 ;; *-dec-osf1.2 | *-dec-osf1* ) opsys=decosf1-2 ;; *-dec-osf3.[2-9] ) opsys=decosf3-2 ;; *-dec-osf3* ) opsys=decosf3-1 ;; *-dec-osf4* ) opsys=decosf4-0 ;; Can someone better at shell see why this is happening and why didn't it happen with the patched version? Unfortunately I had to delete the patched version to have room for the full one and can't compare the configure scripts. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 participants
0 comments

Re: Bug: png files at cvs.xemacs.org 26 years, 7 months

SL Baur

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes in xemacs-beta(a)xemacs.org: > SL Baur wrote: >> > [snip] >> Just to be clear. You're referring to about.el (ie. etc/photos/*.png), >> right? The .pngs in the top-level etc/ directory don't appear to have >> -kb as a sticky option. If about.el doesn't work in 21.2, something >> else is wrong. > None of the .pngs under etc/ and etc/photos/ obtained by 'cvs checkout > -r release-21-2 xemacs-20' are valid according to both XEmacs 21.0 and > another image viewer. Are you seeing any sticky options at all? $ cd ~xemacs/xemacs-21.2/etc/photos $ cvs status -v slb.png =================================================================== File: slb.png Status: Up-to-date Working revision: 1.1.2.1 Fri Jul 31 19:48:28 1998 Repository revision: 1.1.2.1 /usr/local/xemacs/xemacs-20.0/etc/photos/slb.png,v Sticky Tag: release-21-2 (branch: 1.1.2) Sticky Date: (none) Sticky Options: -kb Existing Tags: r21-0b56 (revision: 1.1) r21-0b55 (revision: 1.1) r21-0b54 (revision: 1.1) r21-0b53 (revision: 1.1) r21-0b52 (revision: 1.1) release-21-2 (branch: 1.1.2) ... > ('cvs checkout -r release-21-2 xemacs-20' is right, isn't it? it gives > xemacs_codename as "Aether-pre5" in version.sh). Yup. > I understand that the -kb flag is a global setting across different > revisions and tags of a file, so it applies equally for the files in > 21.0 and 21.2. It depends on whether files have a common ancestor or not. etc/photos/*.png was introduced after the split, so they were checked into each branch in separately. The 21.0 branch does not appear to have `-kb', but the 21.2 branch does. If the 21.2 branch isn't correct, something else is wrong.

2 participants
1 comments

`elib' is missing from cvs.xemacs.org 26 years, 7 months

Karl M. Hegbloom

I did not see `elib' at cvs.xemacs.org in the xemacs-packages/libs directory. Shouldn't it get added to accompany the new `pcl-cvs'? I wonder how cookies work with widgets in them? :-) When I finally finish these silly textbooks, I'll start finding out.

1 participants
0 comments

Re: Bug: png files at cvs.xemacs.org 26 years, 7 months

SL Baur

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes in xemacs-beta(a)xemacs.org: > SL Baur wrote: >> >> Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes in xemacs-beta(a)xemacs.org: >> ... >> > I think that running 'cvs admin -kb' on each of the *.png files ought to >> > solve the problem. >> >> How strange, I thought I did that. Out of curiosity, do the PNGs in >> the 21.2 branch work? > Same problem. Just to be clear. You're referring to about.el (ie. etc/photos/*.png), right? The .pngs in the top-level etc/ directory don't appear to have -kb as a sticky option. If about.el doesn't work in 21.2, something else is wrong.

2 participants
1 comments

Re: Need internal help please (dynamic loading support) 26 years, 7 months

William M. Perry

"J. Kean Johnston" <jkj(a)sco.com> writes: > On Tue, Sep 08, 1998 at 06:03:07PM -0700, Darryl Okahata wrote: > > > Over the weekend I had what I thought was a bright idea. While Elisp is > > > ummm ... fine and dandy, I figured it would be nice if it were possible to > > > extend XEmacs using dynamically loaded objects. For those applications > > > that are very CPU intensive, it would make more sense (and make for much > > > greater speed) if they were written in C and then loaded into emacs. > > > > Ummm: > > > > 1. It's already been done (and is a part of XEmacs 21.0), but it hasn't > > been widely publicized, because of various remaining issues (which > > might cause the interface to change, etc.). See the source file > > "src/dll.c". > > > > [ Bottom line: it's not yet ready for prime time. Think of it as a > > prototype: you can play with it, but don't depend on it. ] > > Ok ... I had a look at it and the stuff I did for 20.4 was much further > along, and works as well with 21 as it was with 20.4. I dont know how > close 201 is to release, but this is an area I know a great deal about > (the technology, not getting it to play nicely with XEmacs). I would like > to make this work, and believe I can with a little internals help. It > would make things go much faster if I could ask questions and get them > answered rather than wading through large doucments. > > Does anyone really care about this or am I the sole torch barer? The > stuff in dll.c, while its on the right track, is missing lots of > things. I already have them so lets try and save duplication of > effort. Here's what I have got: I'm definitely a fellow torch bearer, since I wrote all the original stuff and the samples. Due to personal issues I've had zilch time for serious hacking since january of this year though. > a) Functions for loading and unloading DLLs. This is all in sysdll.[ch] right now - it should work on just about all known unix operating systems, as well as windows. > b) Function for listing loaded DLLs and their versions Not sure if we really need this or not, but it could be handy for debugging stuff. Save the situation of 'I just changed that .el file, why aren't I seeing my changes'. :) > c) A sensible and similar (to the internals) API, which is partly documented > already. > d) Required patches for the Makefile to propperly support dynamic loading. That should be taken care of already as well. Just need to add some stuff for linux and HP/UX to export symbols to the loaded modules. I thought I had done that already, but it seems to be missing from the CVS versions. > e) Samples that actually work. None of the stuff in modules/* will work at > all, as dll.c is expecting to find a symbol emacs_initialize, which > doesn't exist in any of the samples. Ooops, I must never have submitted my patches... someone changed the dll.c and not the modules, and I'm the only one who really ever builds the modules evidently. _MY_ local CVS tree builds just fine. :) > f) A plan (and 90% implementation) for making it easy for any user to compile > module source and have it loaded. This involves copying the right header > files across and providing 2 shell scripts which invoke the compiler and > linker correctly. I had planned on doing something similar to Perl's Makefile.PL stuff. You would write a Makefile.el script describing your targets and things like that, and: xemacs -batch -e "(require 'makemaker)" -f make-makefile Makefile.el > g) Time and inclination to see this through quickly and correctly :-) We don't want to be too quick about it, but this is something I definitely want to see in 21.x (x > 0). As always, correctness counts more than quickness. :) I'm trying to free up more time for hacking on XEmacs and Emacs, but time will tell. -Bill P.

2 participants
1 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta September 1998