Re: [gentoo-dev] Re: FRC: debtools herd creation
On Fri, 2008-05-16 at 20:06 +0200, Diego 'Flameeyes' Pettenò wrote: Yuri Vasilevski [EMAIL PROTECTED] writes: I will be adding some debian build tools to the tree, and would like to create the debtools herd to associate with the packages. Just please don't add Debian-OpenSSL ;) actually, the ssh-keyvuln would be nice. see #221759 -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote: I'd be happy if some other unpacker is used than lzma-utils - one that does not depend on libstdc++ - I'm sure it can be done, heck it's done in integrated form in some other projects in less than a couple kilobytes of code for the unpacking from a VFS. Meanwhile please consider using the upstream provided .tar.gz tarballs instead and not roll patchsets in .lzma just cause you can. busybox has unlzma and seems to be a part of system. Should also be easy to create a really tiny unlzma from the busybox source and ship with portage, or create a patch for tar or something. -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Fri, 2008-03-21 at 10:20 +, Roy Marples wrote:
Hi List.
I've just removed the code to check for euid when running services and
instead
relying on permissions of the service state dir and testing errno. This is a
good thing, but it does have one side effect.
OpenRC can track daemons by how they were started. So every time you run
rc-status it tests each reported service to ensure all daemons are up. This
also works fine unprivileged on normal boxes - except for hardened where
users can only see their own processes.
This isn't really an easy answer, as we could have installed OpenRC in a
prefix where this wouldn't apply, but we don't know that either.
Ideas anyone?
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED || (HARDENED euid=0) {
/* show if process is running or not */
}
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Fri, 2008-03-21 at 12:08 +, Roy Marples wrote:
On Friday 21 March 2008 10:44:12 Natanael Copa wrote:
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED || (HARDENED euid=0) {
/* show if process is running or not */
}
Ideally I'd like a runtime catch rather than a define for this though, but
that's probably the best idea thus far.
/* pid 1 is most likely owned by root */
hardened = pid_is_running(1);
if (!hardened || (hardened euid==0) {
-nc
Thanks
Thanks for working on openrc.
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
On Fri, 2008-03-14 at 10:09 +0100, Jan Kundrát wrote: Natanael Copa wrote: So since I build a distro where size does matter (uclibc) I realised that even if I submit bugs for broken RDEPEND, there will never be an end to those bug reports. Looking at this thread, it seems i was right. I wonder what you are looking at :(. IIRC thread starter complained about too many wrong RDEPEND. You've been told by multiple developers that we do care about dep correctness and are willing to fix bugs when we hear about them. Problem is not that devs are not willing to fix. Problem is that its to easy to inject wrong RDEPEND in the tree in the first place and only way to get it out from there is to wait for someone to report it. Since many/most devs dont use binpkgs its expected that errors in RDEPEND are there. Might be i have ideas how to fix but I need to gain some experience with repoman before I present those. -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote: I offer my help to fix DEPEND/RDEPEND split issues which is causing me a lot of headaches (along with localizations). For reference, please have a look here: http://planet.sabayonlinux.org/?p=105 I'm another distro builder that uses the Gentoo framework. I can only agree. I had to roll my own binary package format and after a short while I had to do the dependencies myself and just ignore RDEPEND since it was close to useless. While Gentoo is fantasitc to build stuff, the binary packagement has some serious issues. It would be really nice if Gentoo could be better on supporting other binary only package managers. -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Rémi Cardona wrote: Natanael Copa a écrit : But somethimes you just need to accept we don't live in a perfect world. I understood early that nobody cares that much about binpkgs anyway and moved on. I'd say you're mistaken. A lot of people care about binpkg. It's not because a majority of devs don't _use_ them that they are not willing to fix bugs for other use cases. If it would be practically possible I would still use RDEPEND. It worked alot better to build stuff around NEEDED. Same thing can be said about other arches or other OSs Gentoo can run on. and hardened. As for the URL you've provided, I don't know what you were trying to demonstrate because about 3/4th of the bugs were marked as fixed, showing me that your patches got accepted. :) Which is good... isn't it? I wanted to demonstrate that I do submit bugs and very often I submit a patch with it. (so I kinda know what bugs.g.o is) I, for one, encourage you to keep opening bug reports. Don't worry, I will. Cheers -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Chris Gianelloni wrote: On Thu, 2008-03-13 at 14:34 +0100, Natanael Copa wrote: On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote: I offer my help to fix DEPEND/RDEPEND split issues which is causing me a lot of headaches (along with localizations). For reference, please have a look here: http://planet.sabayonlinux.org/?p=105 I'm another distro builder that uses the Gentoo framework. I can only agree. I had to roll my own binary package format and after a short while I had to do the dependencies myself and just ignore RDEPEND since it was close to useless. I'm a distro builder, too, and I haven't been hitting any of these problems. Would you care to point out the actual problems, or will the close to useless comment be our only indication of the perceived problems? Regarding the RDPEND's, there is nothing in the framework protecting the RDEPENDS from be wrong. If its wrong, package still compiles and installs and (almost) everyone is happy. It pulls in unnecessary stuff but who cares? Disk space is cheap. So since I build a distro where size does matter (uclibc) I realised that even if I submit bugs for broken RDEPEND, there will never be an end to those bug reports. Looking at this thread, it seems i was right. That doesn't mean i dont submit bugreports. I do and I very often submit a patch. But there is a limit on how much you can fix in upstream before you need to go other ways. (That applies to fixing package splitting upstream as well btw...) -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Sun, 2008-03-09 at 21:21 -0800, Alec Warner wrote: On 3/9/08, Natanael Copa [EMAIL PROTECTED] wrote: On Fri, 2008-03-07 at 19:48 +0100, Marius Mauch wrote: What exact time constraints and responsibilities are people afraid of? Are those concerns real or just myths? As someone who just sent in the quiz, yes its real concerns. What scared me off mostly is the gentoo politics. The entire process to become a gentoo developer is a scare off. Took me weeks to complete the quiz. I want to help, yes, but I do have a life. If you have other methods to avoid contributors who suck; I'd like to hear them. I don't have any silver bullets, sorry. I can certainly invision cvs ACLs if people are worried about that sort of thing; but it doesn't mitigate the fact that maintainers need to know what they are doing. ACL's... yuck... git might be an idea though. signed-off-by, kernel style. Don't have enough experience with gentoo managemet to know if git fit's the management style. (probably not, since its not used already) Did freeBSD not care if you knew what you were doing? What happens if you totally screw up your package? What happens if you do something malicious? I'm a maintainer not a committer. I don't have commit access. -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Fri, 2008-03-07 at 19:48 +0100, Marius Mauch wrote: What exact time constraints and responsibilities are people afraid of? Are those concerns real or just myths? As someone who just sent in the quiz, yes its real concerns. What scared me off mostly is the gentoo politics. The entire process to become a gentoo developer is a scare off. Took me weeks to complete the quiz. I want to help, yes, but I do have a life. A formal proxy-maintainer could really help in our sometimes blind maintaining duties. What would be the difference between a formal proxy-maintainer and how we handle it currently? It's documented? I hardly know it was possible. I have heard the term proxy maintainer a few time and offerend to become one without beeing 100% what it was. I talked about to become a dev only to be able to maintain a handful ebuilds but was even recommended to not do that due to QA issues. That kind of turned me off [1]. At the same time I go the offer to maintain a package in FreeBSD. I said yes because it was very simple. So I have been a freebsd ports maintainer for years, while it took me years to actually take the step to fill in the quiz, even if i run gentoo on desktop and run my own distro based on Gentoo. I'd probably not do the quiz again but I'd be more than happy to maintain a few packages. Marius -nc [1]http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg15926.html PS. The entire thread is kind of interesting to read. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Fri, 2008-02-01 at 08:54 -0500, Mike Frysinger wrote: On Friday 01 February 2008, Natanael Copa wrote: On Thu, 2008-01-31 at 18:46 -0500, Mike Frysinger wrote: On Thursday 31 January 2008, Natanael Copa wrote: ... I can create a bug on this so we get rid of both perl and debianutils dependency for app-admin/sysklogd. (great for embedded) i dont quite follow ... savelog is already a POSIX script and i dont see it executing perl ... The /etc/cron.daily/syslog.cron executes both savelog and /usr/sbin/syslogd-listfiles - which is a perl script. oh, so you're looking to replace a script syslog provides rather than the savelog script sure, i'd open a bug enhancement request on the topic bug #208560 -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Thu, 2008-01-31 at 18:46 -0500, Mike Frysinger wrote: On Thursday 31 January 2008, Natanael Copa wrote: On Wed, 2008-01-30 at 12:35 -0500, Philip Webb wrote: 080128 Mike Frysinger wrote: now that the mktemp binary has been moved out of debianutils and integrated straight into coreutils, perhaps it's time to ask how important this package is to everyone. current debianutils is part of system and provides: - installkernel - run-parts - tempfile - savelog - mkboot do people consider these things critical ? i dont know the last time i personally needed/wanted any of these ... 'equery d debianutils' gives me app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils) app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils) sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2) The 2nd cb ignored, but the others seem important. I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ? Sysklogd seems to be an important pkg too. savelog is used here to rotate logs from a cron job. I had a user rewriting the whole script the other week so it works without either perl or debianutils. (he replaced 80 lines perl with 7 lines POSIX shell code using sed, awk) I can create a bug on this so we get rid of both perl and debianutils dependency for app-admin/sysklogd. (great for embedded) i dont quite follow ... savelog is already a POSIX script and i dont see it executing perl ... The /etc/cron.daily/syslog.cron executes both savelog and /usr/sbin/syslogd-listfiles - which is a perl script. -mike -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Wed, 2008-01-30 at 12:35 -0500, Philip Webb wrote: 080128 Mike Frysinger wrote: now that the mktemp binary has been moved out of debianutils and integrated straight into coreutils, perhaps it's time to ask how important this package is to everyone. current debianutils is part of system and provides: - installkernel - run-parts - tempfile - savelog - mkboot do people consider these things critical ? i dont know the last time i personally needed/wanted any of these ... 'equery d debianutils' gives me app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils) app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils) sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2) The 2nd cb ignored, but the others seem important. I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ? Sysklogd seems to be an important pkg too. savelog is used here to rotate logs from a cron job. I had a user rewriting the whole script the other week so it works without either perl or debianutils. (he replaced 80 lines perl with 7 lines POSIX shell code using sed, awk) I can create a bug on this so we get rid of both perl and debianutils dependency for app-admin/sysklogd. (great for embedded) -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] POSIX shell and portable
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote: On 02-11-2007 17:35:08 +, Roy Marples wrote: I don't see them as inferior. I see them as more portable and less confusing. Please stop calling it more portable. The shell code you see in configure can in a way be called portable. Your POSIX compliant stuff isn't. It is - in the sense the run in more shells. Roy's POSIX compliant stuff runs on at least a handful different shells. bash scripts runs on only one. (busybox ash can run some bash things but mostly they don't work) bash itself is portable but that is another story. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Opinions Wanted - Arrays again :)
On Sun, 2007-10-28 at 06:46 +, Steve Long wrote: Failing that, a plaintext config file along the lines discussed in [1] would be cool. awk could parse it pretty quickly. [1] http://modeemi.fi/~tuomov/b//archives/2007/01/20/T11_58_29/ Something like Debian's /etc/network/interfaces? http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/interfaces.5.gz Why re-invent yet another format when there already are many out there, well tested over years. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote: Natanael Copa wrote: If you're that motivated why not just start hacking on binary support in portage/pkgcore/paludis? There's always open bugs. I think I did contribute with some patches for qmerge in portage-utils. Unfortunally, its pretty difficult to make a lightweight C (language) only binary installer without having at least the eclasses and GNU tools. It kind of defeat the idea of having a lightweight binary only runtime environment. (lightweight means busybox - which give you most of the basic GNU tools, linux-utils, wget, shell, http server and much more for the size of bash only) Your own binary only package manager would still need to provide Option #2; ie you need to have GNU tools installed to process the binary packages. pkg_* functions could still have GNU stuff in them and those still get run during a binary package install. If we would like to be able to do binary installs without the GNU tools, what alternatives do we have? snip stuff that all takes a lot of effort for zero end-user gain Any other alternatives? Comments? I'd just specify BASH (as I don't see the point in making the distinction as it only applies to build machines) and coreutils/findutils etc. To properly install a prebuilt binary packages you need the pkg_* funcs in the ebuild. Asking everyone to switch coding style for certain functions, just to support the stuff that Gentoo was designed to do from the beginning, seems counter-productive. We already do different for init.d scripts (which is great!) , but sure, I get the point. For every market except embedded, which we've discussed already, BASH is not a major issue: nor are the other tools mentioned. I happen to do embedded. Alternative C is what I do today. Sounds rough :) Thats why I'm interested in alternatives. (I really would recommend #pkgcore as well as there is several years of work to do with binpkgs in that.) So far no packagemanager using the portage stuff (eclasses) are not even close to compete in size for binary only installs. Closest is portage-utils's qmerge but it would need atleast the eclasses and bash which would atleast double the size in comparison what I do today. Looks like i will need to continue do my own stuff. Thanks for you time! Standardising on a certain subset of base GNU tools seems like a good idea to me too. -nc -- [EMAIL PROTECTED] mailing list
[gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote: Mike Frysinger wrote: Fabian has summed it up nicely, thanks. i could care less what your userland is outside of the ebuild environment since it doesnt matter to ebuild writers. you want a deficient runtime environment, more power to you, but forcing that environment onto ebuild developers is not acceptable. off the top of my head, i'd like to see GNU find/xargs added to the ebuild environment. -mike Mike, exactly as I said. That's option #2, and I think it could be a great solution. As for deficient, well, that's in the eye of the beholder. ;) -Joe Question, if you go for #2. Does that mean you will need all the required GNU userland to do binary only installs? It would be highly desireable to be able to do binary installs (write your own binary only package manager) without depending on all the GNU stuff needed to compile the packages. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote: On 10/8/07, Natanael Copa [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote: Mike Frysinger wrote: Fabian has summed it up nicely, thanks. i could care less what your userland is outside of the ebuild environment since it doesnt matter to ebuild writers. you want a deficient runtime environment, more power to you, but forcing that environment onto ebuild developers is not acceptable. off the top of my head, i'd like to see GNU find/xargs added to the ebuild environment. -mike Mike, exactly as I said. That's option #2, and I think it could be a great solution. As for deficient, well, that's in the eye of the beholder. ;) -Joe Question, if you go for #2. Does that mean you will need all the required GNU userland to do binary only installs? It would be highly desireable to be able to do binary installs (write your own binary only package manager) without depending on all the GNU stuff needed to compile the packages. Your own binary only package manager would still need to provide Option #2; ie you need to have GNU tools installed to process the binary packages. pkg_* functions could still have GNU stuff in them and those still get run during a binary package install. If we would like to be able to do binary installs without the GNU tools, what alternatives do we have? Those pops up to my mind: A. move the pkg_* functions out of the ebuild to a separate file. Those have a subset of the EAPI and needs to be posix compliant. B. don't use GNU extensions in pkg_functions and have some way to export them (extract pkg_* functions from environment.bz2). Those can then be used by pre/post script in binary package manager. C. Binary package managers will need to write their own pre/post scripts. Any other alternatives? Comments? Alternative C is what I do today. -nc -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Mon, 2007-10-01 at 23:30 +0100, Roy Marples wrote: On Monday 01 October 2007 22:59:40 Roy Marples wrote: This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. It should be noted that that first draft was developed on bash only. Attached is a patch that fixes quoting on all shells and shift errors on ash/dash/busybox variants. Reuseable code. Great! Also attached is the patched versionater.eclass again. After a quick look I wonder how/if it deals with: 1.01 1.1 -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote: On 01-10-2007 22:59:40 +0100, Roy Marples wrote: I would like to propse a new versionator.eclass for consideration (attached). This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. Code is GPL. It can be reused. shell code that can compare versions is very attarctive. It can be used to write shellscripts that removes all tbz2 but the last version. It can be re-used in runtime-only environemnts. It can be reused on non-gentoo hosts hosting distfiles/tbz2. Or it can be reused in a binary only package manager like http://apk-tools.sf.net (yep, i reinveted the wheel there, just because my uclibc runtime environments dont include python) If it make sense to POSIX compliant shell code in any eclass, it would be version handling code. Thanks Roy! -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 05:39 -0700, Alec Warner wrote: I don't think there is a technical reason to avoid using bash. Ofcourse there is. See first issue mentioned in BUGS section in bash manpage. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 09:26 -0400, Mike Frysinger wrote: On Tuesday 02 October 2007, Luca Barbato wrote: Mike Frysinger wrote: in the general case, dash will typically parse faster than bash. but is this speed gain relevant ? if dash can parse an ebuild in 10% of the time that it takes bash, but bash can do it in a 1 second, do we care ? the majority of ebuilds are going to take magnitudes larger to get the job done (running ./configure make). You may want to parse an ebuild not just for building it ^^ true ... but i'd have to wonder if there's anything worth parsing out that the pregenerated metadata does not provide for you ... pkg_* and stuff that binary package managers needs. Things that creates user accounts etc. I would actually prefer getting that stuff into metadata. It would open up new doors for binary only package managers. i guess if you want to parse an ebuild that isnt in the tree thus lacks metadata ... but we further marginalize the use ... -mike -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-servers/nginx: ChangeLog nginx-0.6.13.ebuild nginx-0.6.12.ebuild
On Wed, 2007-09-26 at 00:43 -0700, Donnie Berkholz wrote:
On 07:16 Tue 25 Sep , Konstantin Arkhipov (voxus) wrote:
voxus 07/09/25 07:16:42
I take it that, for some obscure reason, use_with() doesn't work?
if [ ! -f /etc/ssl/${PN}/${PN}.key ]; then
Are you looking at the live root here, in a src_* function?
Certs and keys shouldn't be generated in src_* at all since you would
ship the private key in binary packets.
Do it in pkg_postinst() if you have to.
-nc
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Thu, 2007-08-23 at 14:17 +0100, Roy Marples wrote:
On Thu, 2007-08-23 at 13:33 +0100, Ed W wrote:
Regarding init scripts.
Init scripts should now be strictly bourne or POSIX shell. ie, no
bashisms. bash init scripts will work, but ONLY if /bin/sh is bash.
Shells as /bin/sh that I've tested and found to be working are
bash
dash
busybox
zsh
FreeBSD sh
Also, as there's no bashisms, that also means no bash arrays.
I presume that this is hitting the /etc/init.d/util-vserver startup scripts
/usr/lib/util-vserver/functions: line 778: `pkgmgmt.guessStyle': not a
valid identifier
Where to log a bug? What's the simplest way to temporarily workaround this?
Log a bug at http://bugs.gentoo.org
The easiest fix is to change the . to _ in the function names.
The util-vserver scripts are very bashish using arrays and every
function is declared as:
function funcname()
{
...
}
Those needs to be redeclared as:
funcname() {
...
}
I mentioned to the vserver list that i was interested to convert the
scripts to POSIX. First he said that he was not against it until he
realized he could no longer use arrays.
http://www.paul.sladen.org/vserver/archives/200708/0025.html
Does anyone have any suggestion to do dynamic variables cleanly without
using arrays?
Natanael Copa
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] SSL certificates in binary packages
On Wed, 2007-08-22 at 13:29 +0200, Raphael Marichez wrote: On Tue, 21 Aug 2007, Natanael Copa wrote: Hi, I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. Hi, If you are really concerned by security, then you do not want to use such automatically-generated certificates. They generally contains fake CN names (e.g. CN=localhost) and they are not expected in a PKI environment: they can't be checked nor trusted. You will generate your own certificates with your own root CA, your own CRL and your own policy. Ofcourse. I'm just telling that there are some public keys available in the binary packages so joe user might believe he has encrytion of his traffic out of the box. The net-nds/openldap package has understood this and calls docert from pkg_postinst() and even includes this comment: # You cannot build SSL certificates during src_install that will make # binary packages containing your SSL key, which is both a security risk # and a misconfiguration if multiple machines use the same key and cert. i guess openldap generates self-signed certificates with generic CN names, and this problem is not solved this way. Difficult to decrypt traffic even if it uses self signed keys. Trivial if you have the private keys. Do whatever you want with it. I was just surprised to find private keys in my binary packages. Cheers, -- [EMAIL PROTECTED] mailing list
[gentoo-dev] SSL certificates in binary packages
Hi, I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. The net-nds/openldap package has understood this and calls docert from pkg_postinst() and even includes this comment: # You cannot build SSL certificates during src_install that will make # binary packages containing your SSL key, which is both a security risk # and a misconfiguration if multiple machines use the same key and cert. # Additionally, it overwrites The net-im/ejabberd seems to create ssl cert from antoher script. The vulnerable packages are: app-admin/conserver mail-mta/postfix net-analyzer/sguil-server net-firewall/nufw net-ftp/netkit-ftpd net-irc/ptlink-ircd net-irc/unrealircd net-mail/cyrus-imapd net-mail/cyrus-imspd net-mail/dovecot net-misc/stunnel net-nntp/inn www-servers/nginx Should I create a bug for every vulnerable package? From a binary packagers perspective I would really prefer to create the certs from init.d script. Thanks! Natanael Copa -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 2006-10-11 at 22:17 +0100, Ciaran McCreesh wrote: On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Spaces in dep atoms would be highly evil, since it'd mean they were | no longer simply space delimited. Commas [foo,-bar,baz] would be | fine... | | Write a better parser then :P Not an issue for me. It's an issue for random people writing scripts, for people using command line things and for people who don't want to use a full parser framework for some quick hack. There's no need to make things harder for random developers here. I tried to write some scripts some time ago and it was completely horrible. I wish more people would have been thinking like Ciaran earlier. btw.. I keep hearing about this paladius. Is it more script-friendly than emerge? -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paladius (was: GLEP 42?)
On Thu, 2006-10-12 at 16:18 +0100, Ciaran McCreesh wrote: On Thu, 12 Oct 2006 14:24:36 +0200 Natanael Copa [EMAIL PROTECTED] wrote: | btw.. I keep hearing about this paladius. Is it more script-friendly | than emerge? Once we get the Ruby interface fleshed out it will be... What about shell scripts? Is it one (or few) big fat executable that can do everything windows style, or is it small cooperating executables unix style? Is fancy/pretty features like colors and prytty output more important than easy-to-use with pipes in shell scripts? -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 00:00 +0100, Duncan Coutts wrote: On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote: With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. Some projects/herds already work this way with good results. We regularly get contributions from users that go into our overlay, get tested by us and other users and then get into the main portage tree some time later. We have a very low barrier to entry, it's just darcs record; darcs send. Then one of the devs reviews and applies/rejects the patch. Easy. If the proxy maintainer is specified as contact person in the ebuild, and will be added to the CC list on bugs posted, the official developer will not need to care about it until he gets a response from the proxy developer. For some of our ebuilds we already have de-facto proxy developers. If it would be possible to become a proxy developer, I'd be maintainer for several packages. Its not the first time I'm offering that: https://bugs.gentoo.org/show_bug.cgi?id=76213#c2 Nobody has ever showed interest and I'm not pushing my services on anyone. But I'd like to do official portage and not any overlay. I have submitted ebuilds to bugzilla that ended up in an overlay somehwere (bug got closed) and has dissapeared for ever. I can't post bugs about overlays in bugzilla, (I suppose) so no updated ebuild have been submitted and I ended up just running my own local overlay. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)
On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote: Natanael Copa wrote: Nobody has ever showed interest and I'm not pushing my services on anyone. Why exactly you don't want to become a Gentoo dev? Because of the byrocracy? Is it worth it to only maintain one single package? Because of gentoo devs always seems to fight? The whole proxy maintainer thing is a bunch of crap. Thanks. Seems to work just fine in freebsd ports. The Gentoo developer will still be expected to be responsible of his/her commits, which means 2 maintainers will spend (approximately) same amount of time testing it. The Gentoo developer would have the final reposability, so yes, he/she might need to test it. But if it doesn't work the Gentoo developer sends an email to the (proxy) maintainer: It doesn't work. Please fix or I won't commit or: The code is too ugly. Please improve or I won't commit. The Gentoo dev can establish a relationship with the maintainer so after a while he/she knows the (proxy) maintainer is trustable and can commit after just a look. This in contrast to dealing with thousands unknown bug reporters. If the (proxy) maintainer doesn't answer, the gentoo dev can either fix it himself/herself or find an new maintainer - which I believe is easier than requiting a new dev, since it does not *feel* like as much responsability, even if it is. Its funny, I use gentoo much more that FreeBSD, I'm a freebsd port maintainer, but nothing for Gentoo (well, im an active bugreporter...) When I submit a fix/version bumb (I submit as maintainer update) to freebsd ports, its normally committed within hours, even if its not a popular port. When I submit fixes for packages in Gentoo bugzilla it get stuck for months. They must have done something right. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)
On Thu, 2006-10-05 at 10:18 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 05 October 2006 10:06, Natanael Copa wrote: When I submit a fix/version bumb (I submit as maintainer update) to freebsd ports, its normally committed within hours, even if its not a popular port. ... And I suppose I can say that with quite enough information at hand, considering that I deal with ports every time a package fails to build on G/FBSD .. the problem is most of the times I cannot make use of the patches used by ports because they are, if not broken, sub-optimal. I buy that one. Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages? I'm trying to be realistic. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Proxy maintainers
On Thu, 2006-10-05 at 00:00 +, Christian 'Opfer' Faulhammer wrote: Tach Natanael, 0x2B859DE3 (PGP-PK-ID) Natanael Copa schrieb: Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages? I'm trying to be realistic. You can. And you can even keep out of dev fights here on the mailing list. On IRC you normally have a good working atmosphere, I always found a person who could do what was needed and they get testing back. Ok. Where's the dev form? I'm initially only interested in maintaining packages where I'm the upstream maintainer as well. Do I have to do the dev quiz etc? If so, I'm not doing it today. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Proxy maintainers
On Thu, 2006-10-05 at 15:47 +0100, Ciaran McCreesh wrote: On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa [EMAIL PROTECTED] wrote: | I'm initially only interested in maintaining packages where I'm the | upstream maintainer as well. Ick. Rarely a good idea. That removes a layer of QA. ok. whatever... so, I have learned alot today. * I can't become a proxy maintainer. (you guys will continue your fight if its a good or bad idea having proxy maintainers and meanwhile nothing will happen) * It's a bad idea for me to become a dev since I only want to maintain stuff I know I will be able to maintain. (I cant start small and take more and more packages over time, when/if I feel I'm able to do more) That leaves me with the conclution that its best to just continue to run my own local portage tree and submit bugreports once in a while and hope for the best, just like I have always been doing. Thanks! -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Hi, everyone. I'm not gentoo dev (yet), but I take the chance to vent an idea I have a while, based on my personal experience in bugzilla. On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote: What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. I think the challenge is the amount of packages. One person could not maintain all packages in gentoo. What you didn't need to be a gentoo dev to be a package maintainer? Lets say anyone could be marked as maintainer in an ebuild. When there is a bug, the package maintainer fixes the bug and submits an updated ebuild/patch whatever. This person has no commit access. Then a committer, a gentoo-dev (someone with little more experience), just take a quick look at it and commit it. This way fewer dev with commit access is needed, and more people from community are able to offload the dev's. This would also make the threshold lower for people to become a maintainer. Personally there are a few packages I could maintain, but I don't think its worth becomming a developer to just maintain 1 single package. I think this how the do with the freebsd ports tree. I am maintainer for 1 single freebsd port without being a committer. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
