On 21:04 Wed 25 Jan 2012, Paweł Hajdan, Jr. wrote:
On 1/25/12 10:23 AM, Thomas Kahle wrote:
I suggest that emerge could signal its various failures via return
codes. That would be useful in automated archtesting:
https://bugs.gentoo.org/show_bug.cgi?id=400705
My opinion is very
On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...]
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
and an easy way to check the list of rdepend is asking our bot:
!rdep ${package}
Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a
On 1/27/12 10:41 AM, Thomas Kahle wrote:
On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...]
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
and an easy way to check the list of rdepend is asking our bot:
!rdep ${package}
Unfortunately it prints a
On Fri, Jan 27, 2012 at 1:33 AM, Thomas Kahle to...@gentoo.org wrote:
On 21:04 Wed 25 Jan 2012, Paweł Hajdan, Jr. wrote:
On 1/25/12 10:23 AM, Thomas Kahle wrote:
I suggest that emerge could signal its various failures via return
codes. That would be useful in automated archtesting:
I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.
On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:
I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.
I'm generally in favor of enabling more hardening features by default
(i.e. reversing the default, so that people who want to disable PIE can
On Friday 27 January 2012 14:02:33 Jason A. Donenfeld wrote:
I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.
i can't emphasize how little i care what RHEL/Fedora do. so the logic of
they do XXX therefore we should XXX holds little sway
On Thursday 26 January 2012 11:55:54 Jason A. Donenfeld wrote:
On Tue, Jan 24, 2012 at 06:58, Mike Frysinger vap...@gentoo.org wrote:
pedantically, PIE+ASLR makes it significantly harder to exploit, not
impossible
if we could get some general performance numbers that show non-PIE vs
On 27-01-2012 20:39:24 +0100, Paweł Hajdan, Jr. wrote:
If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?
Negative from my point of view, this is an issue that the dev-community
can solve themselves without needing a force from the Council.
On Friday 27 January 2012 14:39:24 Paweł Hajdan, Jr. wrote:
If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?
getting the Council to vote on something without real data is premature
-mike
signature.asc
Description: This is a digitally
On 1/27/12 8:45 PM, Fabian Groffen wrote:
On 27-01-2012 20:39:24 +0100, Paweł Hajdan, Jr. wrote:
If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?
Negative from my point of view, this is an issue that the dev-community
can solve
On Fri, Jan 27, 2012 at 3:13 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
On 1/27/12 8:45 PM, Fabian Groffen wrote:
Just implement it in a way that people can opt-in/opt-out on it.
We already have an opt-in (hardened profile), and of course it can be
implemented in a way which allows
On Wednesday 07 December 2011 17:15:47 Mike Frysinger wrote:
the advantage is that it should obsolete the separate kgcc64 package for
most people. and i think it might help out with the multilib bootstrap
issue: you can't build multilib gcc without a multilib glibc, and can't
build a multilib
On Fri, Jan 27, 2012 at 20:39, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote:
The most common argument against it is performance loss I think, and
there are probably less than 10 packages that have some compilation
issues with PIE. In my opinion we can deal with that, and security
benefits are
On Fri, Jan 27, 2012 at 20:43, Mike Frysinger vap...@gentoo.org wrote:
a QA warning doesn't help anyone if we don't have documentation in place
explaining to people how to do this cleanly
This is very true.
@Flameeyes: Could you advise on the best, cleanest way to do this? What
should the
On Fri, Jan 27, 2012 at 21:13, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote:
Again - only if we don't get a consensus here.
Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
binaries*?
# Andreas K. Hüttel dilfri...@gentoo.org (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action.
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.
--
I'm curious abotu why econf uses
${EPREFIX}/var/lib
for the default value of localstatedir, when the GNU coding standards
[1] and autoconf site default examples [2] both suggest
$(prefix)/var
Not that it's a big deal to add
src_configure()
{
econf --localstatedir=${EPREFIX}/var
On 01/27/2012 02:39 PM, Paweł Hajdan, Jr. wrote:
On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:
I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.
I'm generally in favor of enabling more hardening features by default
(i.e. reversing the
On Friday 27 January 2012 16:21:21 W. Trevor King wrote:
I'm curious abotu why econf uses
${EPREFIX}/var/lib
my understanding is that from our sampling of packages over time, it seemed
more common for upstream to expect this to be a path where they would dump
state into. so if we used
On Friday 27 January 2012 16:05:13 Jason A. Donenfeld wrote:
On Fri, Jan 27, 2012 at 21:13, Paweł Hajdan, Jr. wrote:
Again - only if we don't get a consensus here.
Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
binaries*?
he was talking system wide
considering the
hmm, i wonder why mount.nfs is set*id. if we require everyone to use `mount`,
there's no need for `mount.nfs` to be set*id. someone want to point out
something obvious that i'm missing before i adjust the nfs-utils package ?
along these lines, why is cdrtools set*id ? if we have a cdrom
On 01/28/2012 02:14 AM, Mike Frysinger wrote:
hmm, i wonder why mount.nfs is set*id. if we require everyone to use `mount`,
there's no need for `mount.nfs` to be set*id. someone want to point out
something obvious that i'm missing before i adjust the nfs-utils package ?
along these lines, why
On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
On 01/28/2012 02:14 AM, Mike Frysinger wrote:
along these lines, why is cdrtools set*id ? if we have a cdrom group,
and we assign our cdroms/dvdroms to that group, then we already have
access control in place and can skip the
On 01/28/2012 02:41 AM, Mike Frysinger wrote:
On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
On 01/28/2012 02:14 AM, Mike Frysinger wrote:
along these lines, why is cdrtools set*id ? if we have a cdrom group,
and we assign our cdroms/dvdroms to that group, then we already have
Mike Frysinger schrieb:
along these lines, why is cdrtools set*id ? if we have a cdrom group, and
we assign our cdroms/dvdroms to that group, then we already have access
control in place and can skip the set*id.
-mike
From the manpage, In order to be able to use the SCSI transport
subsystem
On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:
On 01/28/2012 02:41 AM, Mike Frysinger wrote:
On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
On 01/28/2012 02:14 AM, Mike Frysinger wrote:
along these lines, why is cdrtools set*id ? if we have a cdrom
group, and we
On 01/28/2012 03:49 AM, Mike Frysinger wrote:
On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:
On 01/28/2012 02:41 AM, Mike Frysinger wrote:
On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
On 01/28/2012 02:14 AM, Mike Frysinger wrote:
along these lines, why is cdrtools
On Friday 27 January 2012 20:28:04 Chí-Thanh Christopher Nguyễn wrote:
Mike Frysinger schrieb:
along these lines, why is cdrtools set*id ? if we have a cdrom group,
and we assign our cdroms/dvdroms to that group, then we already have
access control in place and can skip the set*id.
From
On Friday 27 January 2012 20:49:49 Samuli Suominen wrote:
and people have multiple times tried to convince the cdrtools author to
change this, but without success.
the author can be, well, ...
sure, i'm not expecting him to be anything resembling reasonable. but if we
can reduce set*id
On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile bluen...@gentoo.orgwrote:
Exactly. Jason, if you want PIE across the board (with a few exceptions),
switch to hardened.
What? Are you kidding?
Again, to reiterate, *I AM NOT SUGGESTING HAVING PIE ACROSS THE BOARD.*
What I suggest is that we
On Sat, Jan 28, 2012 at 01:12, Mike Frysinger vap...@gentoo.org wrote:
Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
binaries*?
he was talking system wide
This thread is about PIE on SUID executables.
considering the number set*id binaries in the tree, and
On Fri, 27 Jan 2012, W. Trevor King wrote:
I'm curious abotu why econf uses
${EPREFIX}/var/lib
for the default value of localstatedir, when the GNU coding
standards [1] and autoconf site default examples [2] both suggest
$(prefix)/var
Right, and their $(prefix) defaults to
On Sat, 28 Jan 2012, Samuli Suominen wrote:
i've improved the situation _a bit_:
+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+ 28 Jan 2012; Samuli Suominen ssuomi...@gentoo.org
+ +cdrtools-3.01_alpha06-r1.ebuild:
+ Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
On 01/28/2012 08:28 AM, Ulrich Mueller wrote:
On Sat, 28 Jan 2012, Samuli Suominen wrote:
i've improved the situation _a bit_:
+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+ 28 Jan 2012; Samuli Suominenssuomi...@gentoo.org
+ +cdrtools-3.01_alpha06-r1.ebuild:
+ Change cdda2wav, cdrecord,
# Ralph Sennhauser s...@gentoo.org (28 Jan 2012)
# Hopelessly outdated, contains broken jars. #91484
# Removal in 30 days.
dev-java/sun-j2ee
signature.asc
Description: PGP signature
36 matches
Mail list logo
