# Ralph Sennhauser (28 Jan 2012)
# Hopelessly outdated, contains broken jars. #91484
# Removal in 30 days.
dev-java/sun-j2ee
signature.asc
Description: PGP signature
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 Suominen
+ +cdrtools-3.01_alpha06-r1.ebuild:
+ Change cdda2wav, cdrecord, readcd and rscsi from
> 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
> + +cdrtools-3.01_alpha06-r1.ebuild:
> + Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
> disk for
> +
> 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 t
On Sat, Jan 28, 2012 at 01:12, Mike Frysinger 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 their requ
On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile wrote:
>
>
> 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 have PIE for
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 imp
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.
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 set*
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"
> >>> gr
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
su
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
acc
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 th
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
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" gro
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
consider
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 use
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 def
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
# Andreas K. Hüttel (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.
--
Andreas K. Huettel
Gento
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*?
On Fri, Jan 27, 2012 at 20:43, Mike Frysinger 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 general instruct
On Fri, Jan 27, 2012 at 20:39, "Paweł Hajdan, Jr." wrote:
>
> 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 much more impo
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 multi
On Fri, Jan 27, 2012 at 3:13 PM, "Paweł Hajdan, Jr."
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 opt-out (I even
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 solv
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 si
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 Coun
On Thursday 26 January 2012 11:55:54 Jason A. Donenfeld wrote:
> On Tue, Jan 24, 2012 at 06:58, Mike Frysinger 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
> > PIE, that
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 sw
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
s
I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.
On Fri, Jan 27, 2012 at 1:33 AM, Thomas Kahle 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:
>> >
>> > http
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 print
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 i
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 i
36 matches
Mail list logo
