Hello,
I didn't want to continue this discussion until I have a working F16 setup.
Recently
something got fixed so that install now works...so...
On Tuesday, August 09, 2011 10:39:26 AM Adam Jackson wrote:
On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote:
My main concern is that the
Matthew Garrett wrote:
Unless the checking is part of autoqa this simply isn't
sufficient. There's a huge benefit to implementing it in the way
that's
easiest for maintainers.
The earlier a problem is detected, the cheaper it is to fix. If I have
understood AutoQA right, it gets
On Tue, Aug 09, 2011 at 02:20:53PM +0100, Matthew Garrett wrote:
You can't bring a policy to FESCO, fail to turn up to any of the
meetings and then be surprised if the enacted proposal doesn't perfectly
match yours. The ticket was flagged meeting up until the point where
it was closed which
On Wed, Aug 10, 2011 at 02:46:17PM +0100, Richard W.M. Jones wrote:
This clearly needs to be extended to changes in policy. Flagging a
ticket as meeting is an obscure bit of wonkishness. A courtesy
email should be sent before the meeting instead.
It's helpful to mail feature owners directly
On Mon, 2011-08-08 at 23:16 -0400, Steve Grubb wrote:
I think there should have been some discussion about this on the FESCO
request
I submitted. I have some concerns about what was implemented. Are there bz
filed for this or more discussion about it somewhere?
most of the discussion
On 08/08/2011 06:23 PM, Adam Jackson wrote:
Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
through updates), if you're using a %configure-style spec file, defining
the magic macro is all you have to do. The rpm macros will notice the
macro, and put the right magic into
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
This list is woefully incomplete. I would advocate a much larger list. For
example, sudo is a very important program that we make security claims about.
It is not on that list.
Because it's SUID.
I think there should have been
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote:
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
This list is woefully incomplete. I would advocate a much larger list.
For example, sudo is a very important program that we make security
claims about. It is not on
On Tue, Aug 09, 2011 at 08:47:16AM -0400, Steve Grubb wrote:
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote:
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
This list is woefully incomplete. I would advocate a much larger list.
For example, sudo is a very
Steve Grubb wrote:
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote:
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
This list is woefully incomplete. I would advocate a much larger list.
For example, sudo is a very important program that we make security
On 08/09/2011 08:47 AM, Steve Grubb wrote:
My main concern is that the macro will be misapplied and overall performance
will take a hit. I don't know how a macro can tell the intent of an
application as it links it. There has not been a chmod so that it knows this
is setuid and needs more
Steve Grubb wrote:
This is not the policy that I asked for.
Well, what Ajax described isn't a policy at all. It's a set of RPM macros
designed to make it easier to follow the (soon to be) policy. RPM macros can't
enforce the policy. Enforcement must be done elsewhere.
When you make a PIE
On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote:
Taking RHEL6 through common criteria and FIPS-140, filing dozens of
security bugs after studying some problems and sending patches. I am
monitoring the FESCO ticket, but I don't monitor fedora-devel all the
time because there
On Tue, Aug 09, 2011 at 10:17:29AM -0400, Steve Grubb wrote:
On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote:
You can't bring a policy to FESCO, fail to turn up to any of the
meetings
I didn't fail to turn up to any of the meetings. I watched the issue and
attended until
On 08/09/2011 10:17 AM, Steve Grubb wrote:
I didn't fail to turn up to any of the meetings.
...
I would rather have seen a macro added to auto tools to detect gcc support
for this so that upstream developers can more easily add the support natively
for all distributions.
So you just failed to
On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote:
My main concern is that the macro will be misapplied and overall performance
will take a hit.
That's a valid concern, but any hardened build would have this problem.
I'm happy to talk about how the performance impact can be mitigated, but
Matthew Garrett wrote:
Unless the checking is part of autoqa this simply isn't
sufficient. There's a huge benefit to implementing it in the way that's
easiest for maintainers.
The earlier a problem is detected, the cheaper it is to fix. If I have
understood AutoQA right, it gets involved
On Tue, Aug 09, 2011 at 04:53:16PM +0200, Björn Persson wrote:
Matthew Garrett wrote:
Unless the checking is part of autoqa this simply isn't
sufficient. There's a huge benefit to implementing it in the way that's
easiest for maintainers.
The earlier a problem is detected, the cheaper
tl;dr version: If you have a security-sensitive package, and wish to
enable some gcc-level hardening features with a modest performance
impact, you will soon be able to enable them (nearly) automagically by
rebuilding with this line in your spec file:
%define _hardened_build 1
Now for the
Hi,
On Mon, Aug 08, 2011 at 12:23:43PM -0400, Adam Jackson wrote:
%define _hardened_build 1
just wondering: Is %define really correct here or does it need to be
%global?
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 8/8/11 3:52 PM, Till Maas wrote:
On Mon, Aug 08, 2011 at 12:23:43PM -0400, Adam Jackson wrote:
%define _hardened_build 1
just wondering: Is %define really correct here or does it need to be
%global?
I've been using %define out of habit, but either one works.
- ajax
--
devel mailing
On Mon, 2011-08-08 at 12:23 -0400, Adam Jackson wrote:
If you've made it to the end, congratulations. Please let me know if
there are any issues, or any questions I can answer. In particular if
the performance impact of these flags is excessive for you, there are
some ways it can be
* 3: what does this mean for you?
... and your users, and your software maintenance budget:
If you enable it, then the apps in your package:
1) Cannot be prelink-ed. This likely costs time and space (RAM, swap)
at run time. The magnitude of the cost can vary from almost nothing
to several
On Monday, August 08, 2011 12:23:43 PM Adam Jackson wrote:
* 2: how do we go about doing it?
All of this is only an issue because most build systems don't let you
say different CFLAGS or LDFLAGS for shared libraries and executables.
Sigh.
So instead, we'll teach gcc to figure it out. To
24 matches
Mail list logo
