Re: [gentoo-dev] Re: Modular X and hardened
On Sat, 13 May 2006 23:04:10 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
Kevin F. Quinn (Gentoo) wrote:
Oh, OK, let's argue semantics. It's suggested by a hardened user on a
bug the hardened team is CC'd on, but the team didn't say anything was
wrong with the change.
That's because for the moment we don't have a better suggestion; we
can't say don't do it in this case until we have a solution. Our
silence doesn't mean we like the solution; it means we haven't got
anything better to suggest for now.
With regards to Duncan's (non-hardened) problem, adding:
filter-ldflags -Wl,-z,now
to x-modular.eclass as he suggests should be fine; his issue is
different to that with the hardened compiler in as much as he has
added the '-Wl,-z,now' to LDFLAGS as advised by the QA message and
the above filter will just remove it again; whereas to deal with
the hardened compiler we need to reliably add a flag to all the
relevant link commands (the bit that takes the effort is working
out which are relevant).
Now I'm confused. Do you want this filter instead of the current
situation, in addition to, or what? This is exactly why I asked for a
patch.
This is a completely separate issue, nothing to do with the hardened
team or the hardened compiler. It causes the same problem in the end,
but a completely different way.
The QA checks in portage advise the user to try:
LDFLAGS='-Wl,-z,now' emerge ${PN}
because the X server is suid, dyn linked and using lazy
bindings. This warning becomes fatal if FEATURES=stricter,
so you may want to RESTRICT it (which doesn't remove the warning, so
you should be able to find it in your build logs for xorg-server).
In summary, for Duncan's issue I suggest adding:
# Xorg server is unaviodably suid with lazy bindings
RESTRICT=stricter
to the xorg-server ebuild to stop it dying for people with
FEATURES=stricter (the comment helps people who have enabled STRICTER
to see why it's disabled, in case anything else crops up) and also to
add:
filter-ldflags -Wl,-z,now
to the eclass (perhaps in x-modular_src_compile, or in both
x-modular_src_config and x-modular_src_make). If you do it just on the
xorg-server ebuild, and people do what Duncan did and set LDFLAGS in
make.conf, it'll set BIND_NOW on everything which at the very least
will cause the radeon and GL drivers to fail to load.
Obviously I haven't tried it so it would be useful if Duncan could
raise a bug with the exact change he made.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Modular X and hardened
On Sun, 14 May 2006 12:46:23 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The idea of filter-ldflags is a bad one, IMO. There are an infinite number of ways to enable a flag (for -z now: -Wl,-z,now; -Wl,-z -Wl,now; -Xlinker -z -Xlinker -now; -Wl,-O1,-z,now; ...). Even if you restrict yourself to the sane ones, you can't reasonably catch them all. That's true enough, however if people follow the QA instructions they'll do the -Wl,-z,now version. People doing other variations can get picked up when they raise a bug with emerge --info. Or we could make filter-ldflags more intelligent, of course. Normally, the proper fix would be `append-ldflags -Wl,-z,nonow` Ideally, yes - but as you note, -z nonow does not exist. BTW '-nonow' is a separate thing (note, no '-z'), added by us to the hardened compiler specs to switch off the automatic -z,now we do on links. but as binutils completely ignores this, that's not going to work either (as also noted earlier). I think the only sane thing to do (treating -Wl,-z,now -Wl,-O1 differently from -Wl,-z,now,-O1 is not sane) is to give a warning message telling users not to enable -z now even if portage states otherwise. Ideally, binutils would also be patched to support -z nonow, and -Wl,-z,nonow would be appended to LDFLAGS, but that's something for later concern. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Modular X and hardened
On Sat, 13 May 2006 11:32:49 +0200 Simon Strandman [EMAIL PROTECTED] wrote: Kevin F. Quinn (Gentoo) skrev: On Fri, 12 May 2006 10:49:22 +0200 Simon Strandman [EMAIL PROTECTED] wrote: I installed modular X on my server running hardened. X on a server? If it's just for the libs that's ok, but running the X server itself is risky on a server as it's huge and suid so flaws can easily gain root access. One such was discovered just the other week (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526). I have my reasons. I need to run VNC on it. ok; just remember that by building vanilla you lose PIE and SSP as well (either of which can reduce the impact of buffer overflow exploits from privilege escalation to denial-of-service or less). For anyone else considering it, hardened advise sticking with 6.8 for now. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Modular X and hardened
On Sat, 13 May 2006 13:10:22 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Ned Ludd wrote: This was handled in the 6.8.x series and got dropped for unknown reasons when the modular X porting started happening. Unless your dead set on modular X I'd stick with the 6.8.x series. We are using the solution that was suggested to us by members of the hardened team. The current solution (bail if -z,now is set in the compiler specs) is not one suggested by the hardened team, just need to make that clear, and it's not something we would encourage elsewhere. However until we can provide a solution for such a high-profile package we are not going to make a fuss. Our suggestion was to 'append-flags -nonow' on the server and video driver builds, but when a helpful user tried it, it wasn't enough - we simply haven't had the resource to work it out properly yet. If you have a different solution, please do submit a patch for it. With regards to Duncan's (non-hardened) problem, adding: filter-ldflags -Wl,-z,now to x-modular.eclass as he suggests should be fine; his issue is different to that with the hardened compiler in as much as he has added the '-Wl,-z,now' to LDFLAGS as advised by the QA message and the above filter will just remove it again; whereas to deal with the hardened compiler we need to reliably add a flag to all the relevant link commands (the bit that takes the effort is working out which are relevant). Duncan - perhaps it would be useful if you could raise a separate bug about the QA message and Xorg, and attach the diff you apply to x-modular.eclass. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Modular X and hardened
On Fri, 12 May 2006 10:49:22 +0200 Simon Strandman [EMAIL PROTECTED] wrote: I installed modular X on my server running hardened. X on a server? If it's just for the libs that's ok, but running the X server itself is risky on a server as it's huge and suid so flaws can easily gain root access. One such was discovered just the other week (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526). It was quite annoying to have to switch back and forth betwen the vanilla gcc and the hardened. I couldn't leave it on compiling over the night but had to monitor it all the time. Is this really necessary? Why can't the modular X eclass just append the appropriate CFLAGS/LDFLAGS that disables bind now or whatever it is thar breaks X instead? It could, if we had the time to get it working. It should work passing '-nonow' to all invocations of gcc that do linking of relevant bits, but for some reason when people have tried that it hasn't worked - see bug #110506. We (hardened) haven't had the time to investigate further, and we don't want to complicate the stabilisation effort of modular X (which is a big enough job as it is) so we've left it as it is for the moment. We'll probably start looking at it again once it becomes stable (also upstream have a pending task to resolve the issue properly, but don't hold your breath). P.S. there's a hardened mailing list that is relevant. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thu, 04 May 2006 16:29:56 -0700 Michael Kirkland [EMAIL PROTECTED] wrote: This leads to people trying to maintain a frankenstinian /etc/portage/package.keywords file, constantly adding to it and never knowing when things can be removed from it. If you use specific versions in the package.keywords file (i.e. do =category/package-version-revision ~arch instead of category/package ~arch, this doesn't happen. You just need to watch for downgrades in case a ~arch version is removed without ever going stable, and every so often go through it looking for package versions that have been superseded. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Packages that need maintainers
On Thu, 4 May 2006 21:20:48 -0500 spradlim [EMAIL PROTECTED] wrote: I have a question that I havn't been able to find that is somewhat related to the following email. I know and understand Linux very well. I also know how ebuilds work. So how do I go about maintaining packages and getting them into portage. For example I would like to maintain a munin, munin-plugin, and tightvnc ebuild. Where can I find this information. I don't know where to start. Gentoo Developer Handbook, Becoming a developer http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 In the first instance, do the work on bugzilla. Look for open bugs for existing packages, and post fixes/patches there. For packages not currently in portage, raise a new bug. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Fri, 5 May 2006 13:20:09 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: On Friday 05 May 2006 08:32, Kevin F. Quinn (Gentoo) wrote: If you use specific versions in the package.keywords file (i.e. do =category/package-version-revision ~arch instead of category/package ~arch, this doesn't happen. Hardcoding specific ~arch versions or revisions unless absolutely needed is a bad idea. Remember that we don't do GLSA's for testing stuff. If bleeding edge, then bleeding edge. I disagree. Your argument is for not using ~arch at all, rather than an argument against keeping control of what you have from ~arch. If I want something from ~arch, it's for one of two reasons: 1) There's a feature/fix that I need now 2) I want to try out a new version of something for fun I certainly don't want to take everything from ~arch; that way leads to regular system instability. In practice, I tend to do: =category/package-version* ~arch so that I pick up -rN bumps on unstable versions as this should mean that the maintainer considers the change necessary for users of that version. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Fri, 5 May 2006 16:38:57 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: On Friday 05 May 2006 15:23, Kevin F. Quinn (Gentoo) wrote: I disagree. Your argument is for not using ~arch at all, rather than an argument against keeping control of what you have from ~arch. No. My argument is that category/ebuild is much better than =category/ebuild-x*. If and only if there's a problem with the former, you should take the latter into account and monitor the ebuild changes closely. From my perspective, category/package is worse. It means once a package goes ~arch, it never becomes arch again. My approach means that when I've gone ~arch to get something only available in that version, it becomes arch once the package gets stabilised or a later version is stabilised. In practice, I tend to do: =category/package-version* ~arch so that I pick up -rN bumps on unstable versions as this should mean that the maintainer considers the change necessary for users of that version. So you won't get security updates, when this means it is a version bump. And this is most often the case. Unless you _always_ read the ChangeLogs and referenced bugs of all ebuilds you run testing, this is not safe. First, I'll get the security updates when (1) the relevant updated package goes stable, which is usually pretty quickly, or (2) notification is made in gentoo-announce (which must be the correct place to get such notifications). Secondly, Up-to-date on GLSAs != safe. Not by a long shot. Further, missing GLSAs does not necessarily mean I'm vulnerable. That's what the detail is for in the GLSAs; so I can make a judgement call on whether I need to worry about a vulnerability or not. Lastly, if there are versions of a package in ~arch that have known security flaws, my understanding is that they either get patched with a -rN bump, or they get removed from the tree in favour of a later version that is not vulnerable. Either way, I get notification when I next do an update. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
OK; just to clarify my understanding, and perhaps for anyone else watching who saw things as muddled as I did: 1) A herd is a group of packages, no more, no less. A package must be a member of at least one herd (since the herd entry is mandatory in metadata.xml, and metadata.xml is mandatory). 2) A package can belong to more than one herd. 3) A herd does not have an email address - it's not a person or group of people so an email address is nonsensical. 4) In the first instance, a package is maintained by those listed by maintainer entries in the package's metadata.xml 5) In the second instance, a package is maintained by the people indicated by the package's herd entry or entries at /gentoo/misc/herds.xml 6) The herd entry may specify directly a list of maintainers with optional roles, or may refer to projects or other herds to locate maintainers. Another way of looking at it; herds are a mechanism for locating maintainers for packages. Seems simple enough when written out like that - flame me if I have it wrong :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Wed, 26 Apr 2006 20:29:32 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: To that end, it's been brought up that perhaps the metadata.xml files are partly to blame, in that they imply that the package is maintained by a herd. There is not maintainer-team listed, just a herd. So, I would like to propose that we make this distinction clearer in the metadata.xml files. I'm interested in thoughts that people have on this, but please do cc: me in your response to be assured that I read it. I must admit I've assumed that the herd entry in metadata.xml is a reasonable fall-back if the maintainer entry is missing or the listed maintainer is away/not responding. This is implied by http://www.gentoo.org/proj/en/metastructure/herds/index.xml which requires herd but not maintainer - also the description of maintainer says Besides being a member of a herd, a package can also be maintained directly which implies the herd is the default maintainer if maintainer is not present. The herds project description says, The herds project aims to ensure that the growing number of ebuilds do not overwelm (sic) the gentoo project. To this end the herds project aims for the development of infrastructure that will help manage the collection of ebuilds. This clearly indicates herds are supposed to have a maintainer role. A quick scan of the tree shows that some 6k+ packages have no maintainer entry. It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 27 Apr 2006 10:27:12 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote: I must admit I've assumed that the herd entry in metadata.xml is a reasonable fall-back if the maintainer entry is missing or the listed maintainer is away/not responding. This is implied by http://www.gentoo.org/proj/en/metastructure/herds/index.xml which requires herd but not maintainer - also the description of maintainer says Besides being a member of a herd, a package can also be maintained directly which implies the herd is the default maintainer if maintainer is not present. Well, the herd listing shows what herd that it belongs to, not the team that manages that herd. I think that this is the confusion. For example, catalyst has livecd listed as its herd. However, there is not a livecd project, nor team. Instead, the livecd herd is maintained by myself, solely, except for genkernel and catalyst, that have alternate maintainers. In the case of catalyst, an alias is listed as the maintainer, since there *is* a catalyst team, albeit small. The herds project description says, The herds project aims to ensure that the growing number of ebuilds do not overwelm (sic) the gentoo project. To this end the herds project aims for the development of infrastructure that will help manage the collection of ebuilds. This clearly indicates herds are supposed to have a maintainer role. Where? Two places. First, in the description of maintainer: Besides being a member of a herd, a package can also be maintained directly which implies packages can be maintained by being a member of a herd and secondly where it says: [herds] help manage the collection of ebuilds I interpreted manage to include maintain, since I couldn't think of any other management that needs to be done. If we're to distinguish between herds and teams, and it seems that we should, clearly something needs to define which teams maintain which herds. I can see how you can interpret it like that, but it is anything but clear in stating it. In fact, it mentions nothing about maintaining any packages, but rather to manage the collection of them, which leads me to read it as it is there solely for creating a logical grouping of specific packages, much like how categories work in the tree itself. For example, look at openal. It is a package in the sound herd, yet the sound *team* does not maintain it. I do. A quick scan of the tree shows that some 6k+ packages have no maintainer entry. Well, ~700 of those are games, which belong to the games herd, and have no specific maintainer. The games *team* maintains all packages in the games herd that does not have a specific maintainer listed. It just so happens that in *many* cases, the project (or team) has the same name as the herd to which the package belongs. I think that this has been the cause of the confusion, more than the definitions. I do think that metadata.xml should always indicate who maintains a package, whether it's a single maintainer or a team of maintainers - including who is the backup should the primary maintainer be unavailable for an urgent change. If the herd is nothing to do with who maintains a package, then the maintainer entry should be mandatory; there can be multiple entries and it's easy enough to set up team mail aliases. I also think it should be clear in metadata.xml who the backup maintainers are if such exist - i.e. someone who can process stuff in the absence of the primary maintainer. Maybe other people were assuming, like me, that if maintainer is missing then the herd was the mail alias to write to. I can see from what you're saying that the herd name is not a mail alias (since it doesn't refer to people). It definitely seems that we need to define somewhere which teams maintain which herds. The games example is perhaps obvious, but in general that won't be the case. Perhaps for simplicity (and to save having to edit 6k+ metadata.xml files), we could rule that if the maintainer entry is missing, and the herd name is the same as a team name, that team is the maintainer for the package. It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. I definitely do not think that herds are maintainers. At the same time, I understand that many people do think this, so I'm willing to change *my* definition to match what the in practice definition ends up being, if necessary. So what are the herds supposed to achieve? It would be useful to see some examples of what herds are/could be useful for. I'm happy to go with the intended definition of herd, but it certainly could be clearer in the documentation. -- Kevin F. Quinn -- Kevin F. Quinn signature.asc
Re: [gentoo-dev] Purpose of USE=doc
On Tue, 25 Apr 2006 20:03:00 +0200 Jakub Moc [EMAIL PROTECTED] wrote: I'd like to see some clarification of intended doc use flag usage From what I've gleaned over time, USE=doc is supposed to enable docs that are one or more of: (1) large (2) take a significant amount of resource to build (3) cause extra deps (2) and (3) are usually co-incident. IMHO, of course ;) Whatever we decide USE=doc means, it should be documented as such in use.desc -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 03:31:34 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: Although I don't know darcs at all in terms of use and feature, I would really suggest to _not_ use it. For a simple reason, actually: cvs has almost no cost added, as it's present on every major distribution, system and operating system, being well known and written in plain C with just a few dependencies; svn has a bit more costs, as it requires apr, berkdb and neon, but it's also available on a wide range of different system because it's also in C mainly. If you're suggesting CVS as the second VCS (i.e. in addition to SVN) then I don't see the point - SVN is simply a better CVS and clients should be available on the alt platforms. Darcs, instead, is written in Haskell, which means you need architectures that supports Haskell, and in which it's stable enough to work... considering we have Gentoo/Alt, it's not that good to cut us off (yes I know I should be able to make Gentoo/FreeBSD and maybe other arches to have ghc, but that's not easy and not on my top priority list, while support for overlays can be useful.. for a while we needed java overlay to get kaffe, for example). This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I would be more in favour of GNU arch derived like bzr (bazaar-ng) or mercurial, that are written in Python. While we should know that saying being interpreted means it runs anyway doesn't fly, a working python is already a strict requirement (portage, anyone?) and it's way less pain that ghc, IMHO. I'm also sure bzr works fine on FreeBSD, DragonFly and OSX as I've tried it myself.. Language issues aside, it makes sense to support a distributed VCS in addition to SVN, as that would provide a useful alternative. There's a quick comparison at http://bazaar-vcs.org/RcsComparisons. Of the alternatives to Bazaar-NG, Mercurial (at http://www.selenic.com/mercurial/) looks most interesting, not least because it claims fast local and network performance, which bazaar-ng doesn't. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 11:46:58 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I don't think this is right. All the recent ghc versions have been supplied upstream on many OSs including installers for win32 and OSX. The OpenBSD, FreeBSD Darwin ports systems include ghc. Sorry, yes - I looked at the snapshot download pages where it's linux and mingw32) instead of the release download pages (where it's linux x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X and AIX). However the issue still remains for non-x86/ppc platforms; sparc in particular is likely to be used as a dev platform by some. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 12:37:45 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote: On Sat, 25 Mar 2006 11:46:58 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I don't think this is right. All the recent ghc versions have been supplied upstream on many OSs including installers for win32 and OSX. The OpenBSD, FreeBSD Darwin ports systems include ghc. Sorry, yes - I looked at the snapshot download pages where it's linux and mingw32) instead of the release download pages (where it's linux x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X and AIX). However the issue still remains for non-x86/ppc platforms; sparc in particular is likely to be used as a dev platform by some. I use ghc and darcs on my sparc box all the time. ghc-6.4.1-r2 is currently marked stable on sparc. darcs is currently marked ~sparc. Ahem. Sorry again - I still didn't look at the right page! http://www.haskell.org/ghc/download_ghc_641.html lists sparc, hppa, and also alpha, m68k s390 on debian. I'm currently working on ghc for ia64 since Aron Griffis was interested in using darcs on ia64. It's looking good so far. As Flameeyes pointed out our main problem is with the various Gentoo/ALT systems where we don't have quite enough developer time to allow ghc to get near the top of the TODO list (though we do have it working with ppc osx). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: User created package lists
On Tue, 21 Mar 2006 10:50:00 -0600
MIkey [EMAIL PROTECTED] wrote:
Add the capability for emerge to take a category as an argument,
# (cd ${PORTDIR_OVERLAY} emerge -pv category/*)
Then the user can create overlays with their own category names and
symlink in the package directories they want from the real portage
tree.
This won't work, I think, since depend atoms include the category name
so if one package in the new category depends on another one, it will
use the standard category rather than the symlinked one in the new
category.
However with regards the original question about adding '--list
file' to emerge, you can of course to package lists yourself anyway
as portage exists today. Just create a file with a list of atoms in
it, and do for example:
# cat file | xargs emerge -puv
Doesn't get much easier than that - perhaps I'm missing something :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 11:58:03 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: During that discussion we realized that having utf-8 not enabled by default and no utf8 fonts available by default causes lots of recompilation and reconfiguration. Enabling the unicode useflag in the profiles should help our international users and should not cause any problems. Are there any known bugs / problems this would trigger? Any reasons against that? Enabling support for utf-8 should be fine, but I'd like to sound a note of caution about using a utf-8 locale as a system-wide setting. Since UTF-8 contains holes in the representation (i.e. some sequences of 8-bit values are invalid), when something is asked to parse such invalid data unexpected results can ensue. For an example, see bug #125375 - it turns out that invalid sequences do not match '.' in sed regular expressions (sed-4.1.4). The other gnu tools probably behave similarly. Up to a point this is in line with the UTF-8 spec, which says, When a process interprets a code unit sequence which purports to be in a Unicode character encoding form, it shall treat ill-formed code unit sequences as an error condition, and shall not interpret such sequences as characters. (chapter 3 para 2 rule C12a). This clearly means that the invalid bytes cannot match . (or anything else for that matter). However sed should either generate an error, filter the illegal bytes out of its input, or replace them with a marker (replacement character) - instead it leaves the non-conformant bytes alone. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Wed, 8 Mar 2006 00:17:52 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
how does the attached patch look ? it allows for regexes in the
ignore list which is why i used gawk ;)
Could we add something so that we can disable these ignore lists in the
hardened profile? At least something like:
if [[ -n ${QA_STRICT_TEXTRELS} ]]; then
f=$(scanelf -qyRF '%t %p' ${D})
else
filter version
fi
...
where we can add QA_STRICT_TEXTRELS to make.defaults.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sun, 5 Mar 2006 20:46:25 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote: This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: i hate such things ... imo this information should stay in the ebuild and nowhere else ... I was thinking that the data would be owned by the QA team rather than the package maintainers. I appreciate your pov, however. There may be benefit in being able to set it differently for each profile; for example a hardened (PaX NOELFRELOCS) profile might always have QA_TEXTRELS set empty (i.e. anything with TEXTRELs would fail to install, as it'd fail to run anyway). However package maintainers in general aren't going to like yet more special-casing for the non-mainstream profiles. Anyway, that aside - if you're going for a QA_feature_arch naming, you could use QA_feature where there's no arch difference, supplying others where necessary such that if QA_feature_arch exists it takes precedence over QA_feature. Otherwise you'll end up adding a whole set of variables to all affected ebuilds. Admittedly there aren't that many of them so it may not be worth the hassle. Heh - here's another idea for you to hate: QA_OVERRIDE=EXECSTACK=... x86? ( TEXTRELS=... ) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sat, 04 Mar 2006 19:56:41 -0500 Ned Ludd [EMAIL PROTECTED] wrote: On Fri, 2006-03-03 at 23:32 -0500, Mike Frysinger wrote: so we've found some cases where a package installs objects that either need to be ignored by some of the scanelf checks ... ... what this e-mail is about is naming convention ... i'm thinking that an ebuild sets up a variable with a list of relative paths to $D of files that should be skipped for various checks ... so with slmodem, we'd have like: QA_EXEC_STACK=usr/sbin/slmodemd usr/sbin/slmodem_test if, in the future, we need to add an ignore list for TEXTRELs, we'd use QA_TEXTRELS= This becomes tricky when looking at tests across all CHOSTs. What holds true for one arch defiantly is not the case for others. This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: net-dialup/slmodem QA_EXECSTACK=... QA_TEXTRELS=... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Thu, 02 Mar 2006 00:54:25 + Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2006-03-02 at 00:41 +, Roy Marples wrote: For the non technically minded folks whats the difference between -fno-stack-protector and -fno-stack-protector-all? [...] It was explained to me like this: -fno-stack-protector makes gcc use a heuristic to decide whether or not change a function to use stack-smashing protection. -fno-stack-protector-all makes gcc just do it for every function. not quite (note the 'no-'!): In gcc-3: -fstack-protector switches on stack protection for functions that gcc decides heuristically to be most vulnerable according to their parameters and local data. -fstack-protector-all switches on stack protection for (almost) all functions -fno-stack-protector switches off -fstack-protector -fno-stack-protector-all switches off -fstack-protector-all Of note is that: ... -fstack-protector -fstack-protector-all -fno-stack-protector results in no ssp at all ... -fstack-protector -fstack-protector-all -fno-stack-protector-all results in heuristic ssp switched on For gcc-4.1, the semantics have changed as RedHat Did Their Own Thing and broke backwards compatibility: 1) -fno-stack-protector-all does not exist 2) stack protection is viewed as a three-state setting configured by the last occurring switch from the set -fno-stack-protector - no stack protection -fstack-protector - heuristic stack protection -fstack-protector-all - stack protection on all functions (imo they should have done something like -fstack-protect[N] for N=0,1,2 which would have been clearer, but I got ignored when I suggested it) Since 'last option wins' in the RedHat version, '-fstack-protector-all -fstack-protector' gives heuristic ssp, whereas on gcc-3 it gives full ssp. Upshot - managing ssp has become a bit of a pita :/ (gcc-4 is currently masked in the hardened profile, primarily because gcc-4.0 has no ssp, but going forward also until we decide what to do with the hardened specs on gcc-4.1). there is also: -fno-stack-protector-to-all which if supplied makes -fno-stack-protector get promoted to -fno-stack-protector-all. Apparently -fno-stack-protector-to-all is on by default in all current gcc profiles so that means that at the moment if you specify -fno-stack-protector you really get -fno-stack-protector-all. there is no '-fno-stack-protector-to-all' as such. the gcc specs we change (in gcc-3) currently switch -fstack-protector-all on if -fstack-protector is set (either on the command line or automatically in the case of the hardened compiler). This occurs also with the vanilla compiler - which is a bug although very few people (if any) come across it as the only supported way to use the stack protector at the moment is by using the hardened compiler. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 12:47:33 -0500 solar [EMAIL PROTECTED] wrote: I forget where I read it but I thought that unicode lead to overflows and was considered a general security risk. I wish I knew where I read that but I'm unable to find it. Well, stuff I could find includes: http://www.kde.org/info/security/advisory-20060119-1.txt buggy UTF-8 decoder in KDE - this is an overflow error, which as ciaranm says is a risk applicable to anything. It's a bug in KDE, not in UTF-8 as such. Perhaps this is what was at the back of your mind. http://www.izerv.net/idwg-public/archive/0181.html risks of using UTF-8; in particular the use of separate validators which won't process things exactly the same way the application does. Also homograph risks associated with allowing more than one encoding for a character. http://www.eeye.com/html/Research/Advisories/AD20010705.html example of UTF-8(ish) used to fool IDSs by using alternative non-standard encodings that IDSs aren't aware of. This actually is another example of issues with secondary validators described in the link above - they're not guaranteed to parse things exactly the same way the application does. http://www.microsoft.com/mspress/books/sampchap/5612b.asp describes a number of risks of accepting UTF-8, including the above. So far I haven't found anything that could be considered a general security risk, but that doesn't prove much :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: seeing a new trend of laziness developing.
On Sun, 26 Feb 2006 12:30:50 -0600 R Hill [EMAIL PROTECTED] wrote: Ned Ludd wrote: 232 matches. http://tinyurl.com/pmrmx The vast majority of which have an explanation in the comment directly preceding. In which case it's a moment's effort to cut-n-paste the text into the reassignment/resolution comment. Hence solar's laziness accusation. I'd go further, and suggest that sometimes it's not just laziness (since cut-n-paste isn't any more effort than typing '.') but a deliberate action to avoid explaining oneself. When re-assigning, it is extremely useful for the new assignee to see some relevant text, as this is the first bit of text they may see. If you just re-assign with '.' then the new assignee has to browse the bug to decide how to prioritise etc - which means flipping from your email client to the web browser or whatever. All of this breaks up processing the stream of stuff coming from bugzilla, causing wasted time - all because someone was deliberately evasive about why they reassigned. Similarly when resolving, just saying '.' means other interested parties have to browse the bug to check whether the resolution is valid or not - if there's a decent comment along with the resolution this becomes unnecessary in the majority of cases. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)
On Mon, 20 Feb 2006 14:13:46 +0100 Bjarke Istrup Pedersen [EMAIL PROTECTED] wrote: I was thinking, how about putting all log related packages into their own category? Personally I think unless there is a real problem that needs to be resolved, moving packages around should be avoided. We've been over the problems of the concept of categories many times, I don't see any value in going through it in depth again as categories are too deeply embedded to be changed. Suffice to say that any package is likely to have several reasonable categorisations, however the tree only supports one. Different people will prefer different categorisations according to each person's perspective, so moving packages to suit one perspective just messes things up for another perspective. Maybe creating a logging herd would be an idea to, to remove the load from the base-system herd. Creating a herd is not a problem; obviously herds and categories are completely different things. However a quick scan of the logging-related packages in sys-admin shows they mostly do not belong to a herd, so are not imposing any load on the base-system herd as such. Creation of a herd for these packages would be a question for the maintainers of those packages :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] wrote: Please find attached GLEP 47: Creating 'safe' environment variables. Could you add a definition of 'safe' to the GLEP? It's not clear what this means at the moment. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 19:28:53 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 19 January 2006 18:52, Mark Loeser wrote: Please lets avoid this assumption. I'd love to make it so we never make this assumption anywhere in the tree so that we could actually build GCC without pie or ssp, instead of generating all of the GCC profiles for every user. SPLIT_SPECS=no in make.conf causes just the profile default to be built - is that good enough? pie is in upstream gcc so your argument here is INVALID and -fno-stack-protector is only a problem if gcc-4.0 is built without the ssp-stubs - from 4.1 onwards that'll be upstream as well. Having said that, I don't think we need -fno-stack-protector in default DEBUG_FLAGS anyway, as it doesn't inhibit debug (unlike -Wl,pie). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 18:33:02 -0500 solar [EMAIL PROTECTED] wrote: On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g Mike, how about DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g -fno-stack-protector -fno-pie It's enough to do LDFLAGS=-nopie to get debuggable executables, which might be better as it'd keep code closer to the non-debug code. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Ada compiler: split complete, naming suggestions for gnat-gpl?
On Sun, 15 Jan 2006 10:44:41 +0100 George Shapovalov [EMAIL PROTECTED] wrote: 1. 2005 stands for the standard revision namme (as in Ada 2005) really rather than for a particular version. To elaborate for those unfamiliar with Ada; this is the same sort of thing as C89, C99. Enforcing the previous 83 standard over the current 95 standard can be done by the switch -gnat83; I imagine the 2005 release will add a switch -gnat95. I see two alternatives here: 1. gnat-gpl-2005.1. This keeps it closer to upstream, makes it look like a more real version number and allows trivial increment if an update is released soon (the nearest one is likely to be 2006.1 already although :)) If the 2005 is the standard version then they won't change it to 2006. If they do change it to 2006, then the 2005 is the release date not a reference to the standard - in which case it is the upstream release number :) 2. gnat-gpl-3.4.5.1 This uses the backend gcc version as a base, adding a gnat release indicator to track gnat-gpl specific changes. Further from upstream naming but simplifies SLOT logic in eclass a lot (in the long run, no need to issue one more conditional for another new version). I am leaning more towards option one (gnat-gpl-2005.1), for consistency with upstream reason, as it will be (potentially) less confusing to the users. However I am interested in opinions.. If the 2005 does turn out to be a release date rather than the standard name, then it makes sense as a release version; gnat-gpl-2005 would be enough. Later releases can add a point revision if necessary; if you do 2005.1 now, what happens if upstream release gnat-gpl-2005.1.tgz? Another possibility is gnat-gpl-3.4.5.2005, but I'm not sure that it's worth it. -- Kevin F. Quinn -- Kevin F. Quinn signature.asc Description: PGP signature
