On Thu, 24 Jan 2008 01:37:12 -0800 "laurent FANIS" <[EMAIL PROTECTED]>
babbled:
> > > In Evas:
> > >
> > > $OpenBSD: patch-configure_in,v 1.1 2007/12/06 19:47:08 bernd Exp $
> > > --- configure.in.orig Wed Dec 5 22:13:29 2007
> > > +++ configure.in Wed Dec 5 22:13:42 2007
> > > @@ -31,7 +31,7 @@ AC_SUBST(version_info)
> > >
> > > AC_FUNC_ALLOCA
> > >
> > > -MODULE_ARCH="$host_os-$host_cpu"
> > > +MODULE_ARCH=""
> > > AC_SUBST(MODULE_ARCH)
> > > AC_DEFINE_UNQUOTED(MODULE_ARCH, "$MODULE_ARCH", "Module architecture")
> >
> > you just broke multi-arch support if you install modules to ~/.evas/modules
> > (imagine your homedir is rsync'ed or nfs shared between a sparc solaris
> > box, an x86 solairs box, a openbsd x86 box, an x86-64 linux box. each
> > module will have its binaries in a different arch dir - and will work - as
> > long as you built it for that arch+os. this patch summarily breaks that.
> >
>
> It is irrelevant in OpenBSD's case as EFL and E are installed via the
> packaging system, and that install the correct package in the correct
> place.
> Again i am not trying to push these patches.
the problem is that if there are 3rd party modules for e or engines/modules for
evas- they will install, if compiled by a user who doesn't have root access, to
be in ~/ - and ~/ can very easily be mounted across os's, architectures etc.
and the CODE that LOOKS for modules will LOOK in the os/arch dir for the
os/arch it was built for - in this case it wont look in any dir - and so it
will never find the module you compiled and never work. :( so this only works
as long as every possible makefile for everything you ever install is patched.
if ports patches them all - sure, but you take something outside of ports and
it will be broken unless it is also similarly patched - thus causing confusion
and problems for users :( if the os/arch dir changes because openbsd changed
versions and its in the os string - it COULD be that ABI was broken and thus a
new dir is needed.
> > > AM_GNU_GETTEXT([external])
> > > AM_GNU_GETTEXT_VERSION([0.12.1])
> > > +LIBICONV="$LTLIBICONV"
> > > +LIBINTL="$LTLIBINTL"
> > > +INTLLIBS="$LTLIBINTL"
> > > if test "x$LIBINTL" = "x"; then
> > > LIBINTL="$INTLLIBS"
> > > fi
> >
> > i am dubious about this - why?
>
> This is only for the ports, IIRC this is to prevent linking to
> libintl.a and libiconv.a instead of the .so.
bizarre! why doesn't it link the .so in as it should be available...?
> > > --- src/bin/Makefile.am.orig Fri Nov 9 16:20:53 2007
> > > +++ src/bin/Makefile.am Fri Nov 9 16:21:15 2007
> > > @@ -345,7 +345,7 @@ e_xinerama.c
> > >
> > > enlightenment_init_LDFLAGS = @e_libs@
> > >
> > > -setuid_root_mode = a=rx,u+xs
> > > +setuid_root_mode = a=rx,u+x
> > > install-exec-hook:
> > > @chmod $(setuid_root_mode)
> > > $(DESTDIR)$(bindir)/enlightenment_sys$(EXEEXT) || true
> >
> > you just broke sysactions. e can't shut down, reboot, suspend or hubernate
> > now. it has to be setuid root to be able to run shutdown, reboot etc. as
> > root. there is a sysactions.cfg file- text, that e installs that allows
> > packagers to define access policies and what users, groups etc. can do what
> > and what commands are mapped to which sysaction. you probably should solve
> > this with packaging and install an appropriate sysactions.cfg into openbsd
> > that still allows your average desktop used to do these things as it is a
> > necessary function of using your pc (in almost all if not all cases - if
> > you have access to the power button - you should have access to these). the
> > default sysactions.cfg is set up to "just work" as best as possible and
> > works "as-is" on ubuntu - i guarantee. distributions may/should customise
> > it if needed.
> >
>
> As mentioned above the port system does not allow you to install suid
> stuff, If the user wants it he has to set it by hand.
> sysactions.cfg is being installed correctly via the port system.
is it also configured correctly for openbsd (ie security policies, commands to
run on halt, reboot, suspend, hibernate etc.?)? why blanket "ban" setuid?
> > > CFG_MODULE("exebuf", 1, 1);
> > > CFG_MODULE("winlist", 1, 1);
> >
> > not useful. these are needed for linux - and eventually the wizard will
> > enable or disable modules based on initial system probes the first time you
> > run E. i.e
> > - check if you have any battery (look for apm, acpi etc.) and if not - dont
> > load battery module. check for temp sensors - if you don't have any e knows
> > about - don't load temp module etc.
>
> We will wait for the Wizard ;) till then i disabled them.
no problems. just letting you know why we can't accept such a patch :)
> Or u can use the "safe function" :P .
> All i did is report the nagging from the compiler, i haven't check in
> details all, but they seemed safe.
personally i find just moving everything to "Safe" functions is a false sense
of security - unless you study all the preconditions - strncpy is useless if
"n" passed in is wrong. you "think" it's safe - it's not :) i'm fairly happy
with the state of the code as such as far as safety goes - so unless i find
myself polishing my toenails because i'm so bored with nothing to do.... i'll
leave them :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
