Re: TPMs, measured boot and remote attestation in Fedora

2016-04-08 Thread Gregory Maxwell
On Fri, Apr 8, 2016 at 8:28 AM, Matthew Garrett  wrote:
> Remote attestation is a mechanism by which a remote machine can request
> (but not compel) another machine to provide evidence of the PCR state.
> The TPM provides a signed bundle of information including the PCR values
> and the event log, and the remote machine verifies that the signature
> corresponds to the key it expected to see. The remote machine can then
> examine the log, ensure that it matches the PCR values and analyse each
> individual log entry to ensure that it matches an expected value. In a
> data centre, this means that it can then flag whether a machine is
> running in an expected state or not - if someone has tampered with the
> boot process, the information will not match the policy.
> Doing this well involves knowing what the expected values are to begin
> with. Some of these values come from the firmware, and so we can't do
> much about them without the assistance of the system vendors. But these
> values don't tend to change over the course of a system's lifetime
> (unless you update the firmware), so it's much easier to do something
> about that. Other components *do* change over time as we update grub or
> the kernel, and it's immensely helpful to be able to identify these
> ahead of time.

The TPM style of remote attest is quite unfriendly to free software.
It puts basically the entire operating system in the trusted domain,
and you cannot change even a bit of it without "breaking the seal".
So if you want any use of remote attest at all, there is a huge swath
of your system which are are "compelled" under threat of loss of
access to whatever functionality remote-attest was providing to make
no modification-- or even, potentially, no upgrade to a very new or
less common version.

Even if it is not overtly used in user-hostile ways, many applications
of this would make opaque proprietary operating systems on a much more
even playing field with Free Software.

I think any time invested to make remote attest of any kind work would
better be spent on support for Intel SGX, which creates limited
remote-attestable sandboxes which (assuming Intel made no mistakes :)
) have strong security and confidentiality regardless of what else is
running on the system. These sandboxes also have no outside access
except via limited channels, so (again assuming no mistakes/backdoors
on Intel's part); and the published security model is stronger (e.g.
encrypted ram) and more suitable for user-friendly uses (for example,
it would be straight-forward to use SGX to implement a bitcoin wallet
that could enforce user specified transfer limits, even against a
total security compromise of the host-- and if the RA part is as
usuable as it could be, even prove to third party auditors that your
keys have these security properties (the RA functionality for SGX is
not yet documented in public, AFAIK)).
devel mailing list

Re: More prominent link to verification hashes

2016-02-22 Thread Gregory Maxwell
On Mon, Feb 22, 2016 at 7:42 PM, Kevin Fenzi  wrote:
> My point was that you can get the signatures off the key from the
> keyserver and see if any of them are someone you trust. If not, are
> they connected to someone you trust (hey, look, web of trust). I think
> expanding the web of trust on the signatories of the keys would help
> more than just trying to distribute the key fingerprint "lots of
> places".

They key itself should come with signatures. That it doesn't is weird
and inconvenient. If it came with a single signature by a long lived
key used for the purpose of authenticating keys, it would go a log
devel mailing list

Re: More prominent link to verification hashes

2016-02-22 Thread Gregory Maxwell
On Mon, Feb 22, 2016 at 6:35 PM, Kevin Fenzi  wrote:
> Well, I agree the instructions could do better, but how would that help
> if the site was compromised? The attackers would write their own
> instructions.
> In addition to the verify link, the
> needs a good going over.

New users are stateless and little can be done there; at least not
right now when pre-textual security procedures' like Fedora's are
ubiquitous and thus can't be taken as a clear sign of compromise.

Existing users are another matter; "Hey, wasn't the last fedora key
signed by the fedora-keys-key that I already have?? Something smells
fishy here".   Doubly so if fedora included a fedora-downloader that
users use to get new images which automatically checked these things.

> Pointing people to the sks keyservers to download the key would be nice

I don't think there is any utility in pointing people to a keyserver here.

> and asking them to check the signatures for a web of trust link would
> be great, but I am not sure how many people would care to do that or
> have any links there.

It's useful if that even worked for the few who would do it-- so that
in untargeted replacement they could sound alarms. But I wasn't even
suggesting something so broad as WOT: I'm only suggesting that Fedora
should commit to signing every release key with a long lived, offline
stored, key-- or, alternatively, with prior releases release keys.  So
that people who somehow managed to get a faithful fedora keyring at
some point aren't exposed to compromise over and over again in the

> If the site is compromised how would any of that help?

The compromised site could not sign their replacement keys-- they'd
have to just alter or drop the procedure that provides actual
security, and this disruption would catch the attention of some users.
(and better, if an automated mechanism is provided and gains wide

> This is already done somewhat... the fedora-repos package has all the
> keys in it from the time it was last updated.

That's good. The last I had seen it didn't include key for future
releases.  If they're there now the instructions could simply tell the
user to skip the key download if they're already on an updated fedora

The limitation there is that this need to have virtually no false
positives, and so the lack of updates to that package as versions go
EOL would still be problematic. "Oh, it didn't work. I guess I'll
blindly pull the keys from the site" would undo the security.

> So, if you have a fedora
> install you can check the key in fedora-repos. However, that still
> doesn't get around the fact that the anchor of trust here is the ca
> certificate system, or I suppose, best case it would be a web of trust
> link back to the gpg key, but the web of trust is not that expansive
> and random users who don't care about gpg likely wouldn't have any
> links into the Fedora web of trust.

"Trust anchor" is too narrow a concept-- If the user has to only
successfully get the real keys once and then will be protected after
if they're successful, that is win in and of itself. It also means
that more effort can be rationally expended on those few times
initialization (e.g. trying the WOT method, checking multiple sources,
devel mailing list

Re: More prominent link to verification hashes

2016-02-22 Thread Gregory Maxwell
On Sun, Feb 21, 2016 at 2:32 PM, Sam Varshavchik  wrote:
> One has to jump into the installation guide, in order to find a buried link
> to

The instructions here have you download a set of PGP keys from the
same https webserver which could have been compromised to give you bad
download instructions.

The Fedora 24 key inside it is not signed by any other key. (And even
if it were, no instruction is given to verify the key authenticity;
nor to seek out signatures on the key elsewhere (there is one on the
MIT key servers, but it does no good to users following these

This is security theater.

I've previously complained that Fedora PGP keys are unsigned,
otherwise unauthenticated, and shipped in the same location as the
potentially compromised binaries; and that the verification does
nothing to improve security against compromise of the main download
site, or MITM near enough to it on the network to get a https cert...
to no effect before.

Authenticating keys is hard in general; but existing fedora users
should at least be able to trust-on-first-use chain from earlier keys
to later ones-- assuming the fedora keys are kept offline and not
compromised-- and the instructions should have them verify
accordingly.  But this would require the keys being shipped are signed
with prior releases key (or some static key signing key), and existing
users being told to check for that. It would also be preferable if the
keys were distributed on a separate server on a different network, so
that https would protect users that didn't/couldn't verify the
authenticity of the downloaded keys.
devel mailing list

Re: bundling of jemalloc

2015-03-21 Thread Gregory Maxwell
On Sat, Mar 21, 2015 at 1:31 PM, Paolo Bonzini wrote:
 Firefox and xulrunner are bundling their own copy of jemalloc (try
 strings /usr/lib64/xulrunner/xulrunner |grep jemalloc, or similarly
 with /usr/lib64/firefox/firefox-bin).

 Why isn't this recorded in the RPM provides (and why is there no mention
 of jemalloc in  Are
 there any other known cases outside Mozilla products?  I found bug
 788500 about unbundling jemalloc from redis.

I thought Firefox shipped a highly modified and instrumented fork
(e.g. making about:memory possible),
but perhaps this has changed.
devel mailing list
Fedora Code of Conduct:

Re: New Group Calls For Boycotting Systemd

2014-09-04 Thread Gregory Maxwell
On Thu, Sep 4, 2014 at 9:01 AM, Digimer wrote:
 This reminds me of the Beefy Miracle fiasco... Everyone complained after
 it happened, but few said or did anything before then.

The scope of systemd has crept dramatically since the start. If the
initial discussions of systemd said it would merge dhcp, udev, and
that it would push binary logging, etc.  Do you really think it would
have gone without more vigorous opposition?

Though I share that view that the complaints are misplaced. There are
distributions which don't use systemd or at least make it completely
practical to not use it— e.g. Gentoo. I've begun shifting my systems
to it, even though it receives far less maintenance love than fedora
does because its is dramatically better aligned with my uses and
principles (and the principles of Free Software) than what Fedora has

So I encourage everyone involved in Fedora who is tired of these
complaints to please invite the complainers to pick up Gentoo. More
people using and supporting alternatives will make the alternatives
less costly to use, and ultimately people will feel less like
something is being forced on them against their consent when they have
reasonable low cost alternatives.

It should be perfectly acceptable to tell people Fedora is not for you.
devel mailing list
Fedora Code of Conduct:

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-22 Thread Gregory Maxwell
On Wed, Jan 22, 2014 at 7:47 AM, Richard Hughes wrote:
 Replying to my own email, apologies. I've now gone through the entire
 list of applications-in-fedora-without-appdata. A *lot* of those
 applications haven't seen an upstream release in half a decade, some
 over a decade. I would estimate that 40% of all the apps in Fedora are
 dead or semi-dead upstream.

Sometimes software is just mostly finished. Not getting an updated
version isn't itself evidence of something being dead.
devel mailing list
Fedora Code of Conduct:

Re: OpenH264 in Fedora

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 9:28 AM, Bruno Wolff III wrote:
 The issue for RTC is that we could be using a royalty free codec, such as
 VP8 instead. Accepting the binary makes it more likely that h.264 will be
 made mandatory to implement, which means any company not wanting to
 implement VP8 can always point to h.264 being mandatory as an excuse not to
 support VP8.

Conformance with the specification may require the implementation of
H.264 if the
decision to make H.264 mandatory to implement. This means that those who
care about conformance (e.g. those responding to RFPs) would need to deal
with the consequences.

Many people here have expressed the sentiment that Fedora would be unable to
utilize this option.  This is stark contrast to the claims made to the
working group
so far.

If it is the case that fedora will not utilize this option (or another
to obtain h264 support) and you care about avoiding an outcome where
Fedora is unable to claim conformance with the spec, then someone
probably ought to comment about this to the working group. Commenting
to the WG list may not change the working group's outcome, commenting
here surely won't.

 Another thing to worry about is how the binary is licensed. Accepting that
 license (even in places where software patents don't apply) could
 potentially cause issues. I haven't read the license for it yet, but most

I've seen this sentiment expressed in several posts. There are H.264
patents in the MPEG-LA AVC patent pool current and issued in something
like 46 countries. I haven't checked what percentage of the world's
population the list covers, but I would be surprised if it weren't on
the order of 95%. ( )

In the US, at least, accepting a patent license (even paying for one)
doesn't preclude you from challenging the validity of a patent.
devel mailing list
Fedora Code of Conduct:

Re: OpenH264 in Fedora

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 10:35 AM, Alberto Ruiz wrote:
 Google gave up on that battle, Mozilla gave up on that battle, and
 somehow you expect that the Fedora community can somehow turn the tides?
 There are better ways to push for improvements in this effort (like the
 Daala codec).

Google most certantly has not. ( )

Mozilla's position is In previous discussions of which codec should
be MTI, Mozilla has stated that it could not accept H.264 as MTI,
primarily because we could not deliver H.264 in Firefox. That obstacle
is now removed, and we can accept either codec as MTI.
( )

As I outlined at the thread outset. The most obvious possible outcomes
is one of:

(0) H264 will be selected as mandatory to implement.
(1) VP8 will be selected as mandatory to implement.
(2) There will be no consensus for a mandatory to implement video codec.

(and the market will do what it does but an implementation which was
$not-h.264 only would not be non-conformant with the specification)

The working group had a strong preference going in to have a MTI video
codec (and achieved one for Audio) in order to maximize compatibility.
This benefits is lost if parties will not implement a mandatory one
even if its mandatory.

 Again, the people who have been fighting for open source media
 and the Mozilla organization have already acknowledge that while this
 situation is not ideal, is an improvement over the current situation,
 I'd say we should trust these guys a little when it comes to these
 things, don't you think?

Certainly from anyone's personal perspective OpenH264 existing is
abstractly better than it not existing. It's a hobson's choice: If it
doesn't help you, don't use it. If it does, do. You can't lose.  It
exists now. Hurrah.

I'm commenting here as a Fedora user of many years, but I am a Xiph
developer for many more years (and one of the people working on
Daala), and (as an aside, lest someone think I'm hiding it, a Mozilla
employee). I believe if Fedora developers believe that this will allow
Fedora to ship H.264 that y'all ought to go point it out to the
working group.  The working group can't consider what it doesn't know,
and right now it has been aggressively claimed that that the OpenH264
will make H.264 available at no cost to practical everyone where it
isn't already available.

The question left is will making H.264 MTI be an decision that
excludes free software. I believe that it is— and the comments on this
list suggest other people agree with me. It's hard to make the
argument however when Debian shipping h.264 in the default install and
no one heavily involved with other distributions or working on other
projects speaking up and saying otherwise.

As is was the prior state was Google saying they wouldn't ship H.264
in WebRTC, Mozilla saying they _couldn't_, and a whole lot of loud
legacy equipment vendors (whos stuff is not directly compatible with
WebRTC regardless because of the mandatory DTLS+SRTP, etc) saying that
they won't implement VP8.  Since the OpenH264 announcement the new
claim is that there are no substantial couldn'ts commenting on the
list anymore.
devel mailing list
Fedora Code of Conduct:

Re: OpenH264 in Fedora

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 11:03 AM, Bruno Wolff III wrote:
 I was thinking more of the non-commercial use restrictions you might end up
 agreeing to when you accept the license of the binary. In the places where
 software patents didn't apply, you'd probably either use x264 or build
 openh264 from source to avoid those restrictions.

Non-commercial language is part of the MPEG-LA standard license, I
believe it dates back to MPEG-2 or even before. AFAIK, no H.264
product is licensed for commercial use (whatever that means! the
license doesn't define it)... including things like Final Cut Pro (

Personally I think its just one more of the horrible mess of codec
licensing, it's just one of many ways to violate the complicated
licenses for the licensor to extract more rent from you if its in
their business interest to do so... But in this case the problem is
not specific to OpenH264.

(Though an unwillness to accept a non-commercial license compared to
no license at all is an interesting argument. Though, considering that
OpenH264 somewhat undermines (the least important part of) the revenue
model here, it's not likely that anyone is going to get MPEG-LA to
change their long standing license terms over complaints arising from
that discussion. :)

 codecs process data provided provided by untrusted sources, for security 
 reasons you don't want these bundled with apps.

Codecs have generally had a long track record of security disasters.
This is one of several reasons several major browsers either haven't
used system codecs at all or only by white-listed exception... as many
codecs that get installed on systems have never even been fuzz tested
and, in the past, have been trivially exploitable.

More application embedding for this stuff is probably not a great
plan. A few major applications that have dedicated security teams can
keep up with this stuff, but that doesn't apply generally to all
devel mailing list
Fedora Code of Conduct:

Re: OpenH264 in Fedora

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 11:29 AM, Bruno Wolff III wrote:
 I have asked on the advisory-board list about getting an official Fedora
 position on OpenH264 before the vote occurs. I don't want to be making
 claims about Fedora on my own on how far Fedora will or won't go in
 supporting OpenH264. (This could in theory affect our ability to use the
 Firefox trademark if we block its ability to download that codec from Cisco.
 Assuming that the download is implemented in Firefox.)

Thank you, thats exactly the sort of thing I wanted here.  (In the
IETF posters speak for themselves, with the limits of their own
uncertainty, but it's better to be able to report on an actual
decision where one is possible.)
devel mailing list
Fedora Code of Conduct:

OpenH264 in Fedora

2013-11-02 Thread Gregory Maxwell

Cisco has announced that they will be releasing an implementation of a
BSD licensed H.264 (baseline profile) encoder and decoder, along with
offering download of binaries of it under Cisco's licensing umbrella:

The intention is that any parties capable of obtaining and running the
provided binaries (and they intended to be maximally inclusive of
which platforms they build for) can have a fully licensed
implementation of H.264 at no cost.

This is especially relevant for the new WebRTC standard because the
IETF is in the process of deciding which (if any) video codecs will be
(the minimum) mandatory to implement for conformance with the
specification.  There has been a strong push to establish the
royalty-free VP8 codec as MTI, and an equally strong push (primarily
by vendors of legacy communications equipment with compatibility
concerns) to establish H.264 (and not VP8) as mandatory to implement.

The release of properly patent licensed gratis source available
downloadable binaries has removed the strongest pragmatic arguments of
the parties pushing for VP8 over H.264. (We _can't_ conform to the
spec if it mandates H.264).

It has been argued that no viable platform for WebRTC which cannot
support H.264 already *and* cannot use the OpenH264 library exists or
is likely to arise:

I personally believe it would probably be helpful to the discussion if
Fedora is able to reach a (preliminary?) decision on if OpenH264 (as
described) will be able to be used by Fedora systems (e.g. by having
something analogous to codec buddy go install the codec to give all
Fedora systems H.264 support) in order to provide feedback to the
working group. If a decision to mandate H.264 in WebRTC means that
Fedora systems would be unable to comply with the specification, that
would be unfortunate.

The rtcweb WG session which will discuss MTI video codec will be on
Thursday the 7th at 13:00 pacific. As usual the meeting will be
streamed and anyone can participate remotely via Jabber
(, but feedback can be provided at any time via
the mailing list (and it's probably best to comment earlier rather
than later, links at
devel mailing list
Fedora Code of Conduct:

Re: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Gregory Maxwell
On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters wrote:
 For the client, clearly CPU is not the limiting factor. For regular TLS
 servers, this should also not matter. For fully loaded TLS servers or
 TLS accelerators, the factor 3 on the CPU load will matter, but we're
 talking clusters of machines here. Dropping in a few extra machines
 shouldn't be that hard to give your patent-encumbered endusers PFS.

The difference between DHE and ECDH in TLS is a difference of
supporting supporting about 3,000 connections per second and
supporting something like 800 connections per second (somewhat vague
numbers, opeenssl speed won't bench DH apparently, it's somewhat
slower than RSA encrypt due to the exponentiation by large secret

And this is comparing apples and oranges 256bit ECDSA (conjectured
security involving a best attack 2^128) against DH-1024 (only 80 bit
conjectured security). Comparing with DH-1024 is sort of silly because
people do not consider 80 bit security adequate anymore.  The
comparison with 3072 bit DH is down to more like 200 connections per

But again, and sorry to reiterate but it seems to be have been missed:
 ~No one actually supports the old DHE PFE, and offering it breaks
some clients.  So regardless of the speed concerns, a choice to not
support ECDH is a choice to not have PFS at all, at least on public
facing webservers.

 Ignoring the obvious legal (and now potential backdoor) problems with
 ECC is also not very educated.

I am certainly not ignoring legal concerns. While there are some
patented EC cryptographic techniques, the basic infrastructure
including ECDH over prime fields was first published back in 1984 and
is not patentable.

The IETF has published an extensive RFC covering the foundations of
ECC which carefully shows to-old-to-be-patentable direct citations:

If Redhat is aware of a specific patent concern here, they're keeping
it secret from the public. The continued claims that there are legal
issues here behind basic support really don't make a lot of sense,
especially considering the functionality in RHEL.

(I would also note that the support in RHEL somewhat oddly support
_only_ the parameters from the NSA, which doesn't quite play into the
expressed concern about backdoors)
devel mailing list
Fedora Code of Conduct:

Re: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Gregory Maxwell
On Mon, Sep 9, 2013 at 11:46 AM, Paul Wouters wrote:
 [not speaking for Red Hat]
 You seem to believe only valid legal claims can put Red Hat in court.

Of course not.

Though I'm not aware of anyone making any claims at all over basic
non-specially optimized ECDH on prime fields. Perhaps RedHat is,
though if certicom/rim is out patent trolling on the basic stuff it
would be a shame to keep it a secret: They should take the goodwill
loss they deserve if they're going around claiming to own techniques
published in the mid 80s.

You're going to have a lot of software to remove if the _possibility_
of someone putting RedHat in court is the bar here. There are a _LOT_
more patents on compilers than on elliptic curve cryptography.

Or just patents on simple arithmetic optimizations, lets see US6073150
assigned to Sun.
This one patents computing the absolute value of a signed number using
masking by sign extension: E.g.

Set  mask = x(sizeof(x)*sizeof(char)-1);  absx = (x^mask)-mask.

Oh looky looky, GCC in Fedora 19 on x86_64 compiles int x; x =
abs(x); to this:

sarl$31, %eax
xorl%eax, -4(%rbp)
subl%eax, -4(%rbp)

Good thing nothing in Fedora uses abs() and that Sun's patent's would
never be held by a potentially hostile company so you don't have to
depend on the fact that this technique was published eons before the
since that the invalidity of the claim can't be ensured to keep RedHat
out of court.


And this is an example where we actually do the stuff that is
patented. I do not believe there are any granted but invalid patents
that would preclude using basic ECDH over prime fields.  Maybe there
are and RedHat has heard of some, but if so the world would certainly
like to know that someone actual had a concrete risk here and this
wasn't someone just pattern matching ECC = Patents ZOMG! in a way
that they don't go Compilers = Patents ZOMG!.
devel mailing list
Fedora Code of Conduct:

Re: Fedora/Redhat and perfect forward secrecy

2013-09-06 Thread Gregory Maxwell
On Fri, Sep 6, 2013 at 2:31 PM, D. Hugh Redelmeier wrote:
 | From: Reindl Harald
 | Date: Sat, 24 Aug 2013 11:38:21 +0200

 | looks like Redhat based systems are the only remaining
 | which does not support EECDHE which is a shame these
 | days in context of PRISM and more and more Ciphers
 | are going to be unuseable (BEAST/CRIME weakness)

 It might be the case that the NSA has their fingers in these ECC

 Here's a Schneier article worth reading:

 In it, he recommends (among many other things):

 Prefer conventional discrete-log-based systems over elliptic-curve
 systems; the latter have constants that the NSA influences when
 they can.

 It could be (by accident) that Fedora is more secure due to patents!

The P-256r curve commonly used for ECDH the web has it's parameters
generated by a nothing-up-my-sleeve CSPRNG approach.  I doubt Bruce
was speaking of that... it he was, I think thats a pretty audacious
claim that requires some justification.

Regardless, I think that argument would be an ignorant one:
Approximately no one runs non-ECDH PFS on the web: it's insanely slow
and it breaks clients.  The choice is not between ECDH and RSA based
PFS, the choice is between ECDH and no PFS at all.  Right now Fedora
webservers have no PFS at all.  This can not be argued to be an
devel mailing list
Fedora Code of Conduct:

Re: F20 System Wide Change: ARM as primary Architecture

2013-07-09 Thread Gregory Maxwell
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett wrote:
 llvmpipe has been known to be broken for months, and nobody on the ARM
 team appears capable of fixing it. As a result, ARM shipped in F19
 without any out of the box support for running our default desktop.

 This doesn't make it seem like the ARM port currently has sufficient
 developer expertise involved, and I'd really like to hear what the plans
 are for (a) fixing the existing problems, and (b) ensuring that we don't
 end up in a situation where other architectures are held up because
 there's nobody who can fix ARM-specific bugs.

Does the secureboot situation on arm mean that this primary architecture
will eventually be un-bootable for people running a non-redhat signed kernel?
devel mailing list

Re: Do you think this is a security risk and if not is it a bad UI decision?

2013-05-04 Thread Gregory Maxwell
On Sat, May 4, 2013 at 11:06 AM, T.C. Hollingsworth wrote:
 More to the point, the vast majority of the other software *in Fedora*
 that accepts passwords for any reason hides the passwords as they are
 typed.  If this is really broken (and who knows; neither side has
 really produced much in the way of science), it needs to be fixed in
 GTK (and Qt, and `passwd`, and a bunch of other places), not papered
 over in anaconda.

Without intending to express any support for the change, I do think
it's important to
point out that anaconda is not the same as most of these other cases
because there
is substantial potential for keyboard mapping error. Most of the other
contexts you've
named are on an already running system where its harder to notice that your
keyboard mapping is screwy.

(OTOH, the stakes for a keyboard-remap-password-loss incident couldn't be
lower than during install— at worst you're confused as a result and have to
reinstall, but you don't lose data)
devel mailing list

Re: fltk

2012-12-19 Thread Gregory Maxwell
On Wed, Dec 19, 2012 at 10:40 AM, Bruno Wolff III wrote:
 In some cases you can get DSO linking errors when you don't explicitly link
 to those other packages. People building from source might not care, but
 this can cause problems for official builds.

Can you elaborate on this or point me to where I can learn more?  That
is absolutely counter to my understanding.

Consider: What happens if   you have libfoo 1.0.0  which itself uses
-lbar ...  and later upgrade your system to libfoo 1.0.1 which itself
is -lbar -lm (and is API/ABI and functionally identical).  If I
understand you correctly you're saying that now random -lfoo users
which themselves make no use of -lm will now randomly fail.  I believe
this is incorrect and would be a terrible problem if it were true.

AFAIK, you should only link your actual direct dependencies. If they
have their own dependencies the dynamic linker will handle it, and
anything else leads to madness. Am I full of it?
devel mailing list

Re: fltk

2012-12-19 Thread Gregory Maxwell
On Wed, Dec 19, 2012 at 11:42 AM, Adrian wrote:
 This attitude is why people leave redhat for debian/ubuntu, get fltk right
 and the rest will follow.
 We have tested already.

Adrian, no disrespect intended— but I believe you are making a mistake
here.  It looks like package you're having trouble linking has
incorrect parameters and just happens to work on ubuntu due to leakly
pkgconf linker flags— it's not exposing its own direct dependencies
and the correct solution is to fix it, not fltk. While I'm possibly
mistaken due to some subtle detail of how the FLTK headers are setup I
think that is unlikely.

Everyone working on Fedora cares about doing the right thing— and
helping the packages Fedora packages do the right thing.  The tone
you're taking is unnecessary insulting regardless of how correct you
are... but when that kind of tone is combined with being incorrect it
contributes to an environment where developers justifiability have low
regard for some user complaints.  Since people care about doing the
right thing the tone isn't required nor is it helpful.
devel mailing list

Re: fltk

2012-12-19 Thread Gregory Maxwell
On Wed, Dec 19, 2012 at 11:53 AM, Dan Williams wrote:
 It's the other way around.  If libfoo 1.0.0 linked with -lbar and -lm,
 and then you upgraded to libfoo 1.0.1 which *no longer* links to -lm,
 now stuff that links to libfoo might fail if those things did not
 specifically request -lm themselves when they were built, and they need

Ah. I read your statement backwards.

I think we're in agreement. Everyone should (really, must) link their
own dependencies explicitly, and pkgconf style config lines should
generally only list the library itself to avoid creating a situation
where the caller fails to correctly identify its dependencies and
doesn't know it. But maybe fltk intentionally does something
inadvisable here.
devel mailing list

Re: remove polkit from core?

2012-11-14 Thread Gregory Maxwell
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams wrote:
 Great - let's take something that people are using, remove that
 functionality, and not announce it!

 This is not cool; it represents one of my biggest frustrations with a
 bunch of the new and improved ways of doing things.  You track down
 how to do something, it works for a few releases, and then it doesn't
 anymore with no notice.

I don't mind this much in isolation—  and to some extent its
unavoidable if there is to be progress.

I also have the experience and impression that Fedora often dismisses
use cases in the 'long tail' as things that power users can get by
twiddling some opaque config file or registry entry or hacking some
bit of code— this happens more often the closer you get to the
desktop, but believe its a culture which permeates the project more
generally than that.  In isolation this too would be occasionally
frustrating but finite in baddness.

The combination of the two— that anything non-stock is subject to
constant and often undocumented breakage _and_ that many non
nearly-universal use cases are too non-mainstream to consider
supportable stock features really diminishes the value I receive from
using a distribution at all.

More on the subject— in this brave new polkit JS world,  when an
administrator is considering upgrading their Fedora (or even some
packages),  what tools will they have to validate that their local JS
actually works at all much less produces the desired behavior?   I
don't see any tools or documentation to facilitate that.It seems
to me that adding a bunch of unsound programmatic configuration which
can't reasonably be used by the end users due the overhead of keeping
up regular fedora churn, especially absent good validation tools, is
not a productive change relative to just baking in the additional
logic and exposing it via basic configuration switches.
devel mailing list

Re: twolame - legal

2012-08-16 Thread Gregory Maxwell
On Thu, Aug 16, 2012 at 5:27 AM, Nikos Roussos wrote:
 I happened to notice that twolame is currently on rpmfusion. Is there a
 legal reason for that?

 twolame is an MP2 (MPEG-1 Audio Layer II) encoder (not mp3), which seems to
 be a free (as free of patents) codec. There was a similar discussion on
 Debian and they concluded that it's ok to have it on the official repos.

Debian also has implementations of H264 in the official repos.
devel mailing list

Re: prelink should not mess with running executables

2012-07-16 Thread Gregory Maxwell
On Mon, Jul 16, 2012 at 9:30 AM, Robert Nichols wrote:
 That would mean that prelink would skip much of a running system, and a
 full prelink could be done only by booting from separate media.  Not going
 to happen.

But now that Fedora will have reboot for updates... problem solved, right? :)
devel mailing list

Re: Licensing change: Audacious - GPLv3 -- BSD

2012-07-10 Thread Gregory Maxwell
On Tue, Jul 10, 2012 at 3:48 PM, Martin Langhoff wrote:
 Yes. And also told Oracle that it was very limited what they could
 claim as damage caused by the copyright infringement over those 9

Very limited in the context of billion dollar lawsuits.
Statutory infringement for commercial use makes any infringement a
potentially non-trivial
at the level of mere mortals. Besides, the damages are generally irrelevant the
FUD and disruption are the real costs.  The only litigation that ends
up in front
of a judge are where one or both parties is either crazy or a fool.
Everyone else

But this is a silly discussion. There is substantial jurisdictional
differences on the
bar of copyrightability, and because there are basically no useful bright lines
the details are basically not worth discussing.

The point is that being cautious and conservative is a very good
policy and about the
only one which can be sanely advocated.  If someone's contributions are
really insignificant then it's no big deal to replace them if they're
being unfriendly
and are unwilling to go along with a re-licensing. It may be a bit of a pain,
but it's much less of a pain than.. this discussion not to mention the pain
of a potential legal dispute.

And no, re-licensing a many-authored project isn't simply fun or easy.

This is also a reason why projects should practice good hygiene upfront, and
checking up on this— and propagating best practices— is one of the services a
packager can provide to their upstreams.
devel mailing list

Re: Licensing change: Audacious - GPLv3 -- BSD

2012-07-09 Thread Gregory Maxwell
For a point of accuracy—

On Mon, Jul 9, 2012 at 12:10 PM, Michael Schwendt wrote:
 Have you had your name and a copyright statement in any source file?
 To highlight that you've been the [primary] author of that file? If not,
 you're not a full/official author to have a stake in the licensing

This is a bogus theory of law here.  No Berne signatory nation may
require any notice
or registration to enjoy the protection of copyright.

That someone's name wasn't listed in the right places may _explain_ their
non-inclusion in a copyright change discussion, but it doesn't make it
or lawful.

Perhaps his contributions were too insignificant to earn copyright
coverage, or at least too insignificant to make blockading a licensing
change by the other developers an ethical move, or perhaps they were
all removed as part of the process or through code churn,  but none of that
has much to do with where an author's name is listed.
devel mailing list

Re: Licensing change: Audacious - GPLv3 -- BSD

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 3:17 PM, Michael Schwendt wrote:
 and arbitrary other people, who get their patch contributions merged,
 don't gain any copyright protection on the file or the proper parts of it,

This is not true, and it's the point I was responding to correct.

(I consulted an attorney specializing in US copyright before posting my message
as well, which was why there was a multi-hour gap between your message
and mine.
I point this out not as proof that what I'm saying is correct but
to make it clear that my response wasn't just casual navel gazing.
It sounded like you were advocating an understanding which was inconsistent
with the law, and your follow-up appears to confirm that I wasn't
misunderstanding that much)

It's certainly possible for contributions to be so minor that they gain
no copyright. But this determination can be complicated and fact
specific. Certainly the dividing line is not one of updating the copyright

 and the lack of attribution in the copyright notice makes it very easy
 to forget/ignore/disregard who may have committed a substantial part of
 the file.

Absolutely. It makes it easy to do the right thing and so its a best practice
 to make sure all the names get listed, and its an understandable and forgivable
mistake when someone unlisted gets forgotten. But it doesn't make it appropriate
or lawful to change the licensing without the consent the relevant copyright
holders, even if they aren't listed, such errors need to be corrected
when discovered.

(At least if the forgotten people are actually copyright holders, and that
depends on a lot of details which I'm not aware of for this case)
devel mailing list

Re: *countable infinities only

2012-06-25 Thread Gregory Maxwell
(I'm posting in this thread rather than starting a new one in order to
respect people who've spam-canned it)

It is being widely reported that Canonical's be signing the kernel,
they won't be requiring signed drivers, and won't be restricting
runtime functionality while securebooted. What is being claimed is
that the only thing they'll be restricting is the bootloader and
they're going to write a new bootloader for this in order to avoid
signing code written by third parties.

This seems a bit incongruent with many of the claims made here about
the degree of participation with cryptographic lockdown required and
the importance of it.

I feel like the entire discussion has been a bit unfair where people
were repeatedly challenged to offer alternatives when things claimed
to be impossible based on NDAed discussions are, apparently, actually
possible and the remaining weak alternatives were discarded as not
being usable enough.

devel mailing list

Re: Space wasted by Non English Packages shipped by Default on Fedora 17.

2012-06-25 Thread Gregory Maxwell
On Mon, Jun 25, 2012 at 1:11 PM, Bill Nottingham wrote:
 To elaborate - dejavu-sans-fonts is the default font for English. However,
 it also happens to have Arabic, Greek, accented European, etc. characters,
 so 'support' for those languages will show up as being installed.

And if you use the web you really do want those characters being
installed— otherwise you'll have hexboxes or blank spaces showing up
all over Wikipedia articles or in people's usernames on forums.
devel mailing list

Re: *countable infinities only

2012-06-25 Thread Gregory Maxwell
On Mon, Jun 25, 2012 at 1:56 PM, Peter Jones wrote:
 I feel like this is quite patronizing.  We've stated time and again that we
 don't believe the scenario you're preaching has any real /viability/, and

Sounds like you're not arguing with me, you're arguing with Canonical.

I didn't propose this, the only stuff I proposed fit within the
invariants you set out: That the rules of the game required you to
restrict the system thusly if Fedora was to boot at all.

I was under the impression that you couldn't get a key like that
signed in the first place. But what do I know, it seems like the
experts at canonical don't agree and are going to try several other
routes concurrently.

Canonical seems to be giving this a higher level of organizational
attention[1], vs pure decision making by the engineering guys deep in
the trenches. Obviously this has system implications far beyond a bit
of bootloader code.  And as a result it appears that they have a plan
which will make a better stand for software freedom while
simultaneously satisfying the PR interest of not capitulating to
Microsoft, for whatever value that has.

 so we've chosen not to propose it.  There's no secret here - it's possible
 to do, but we don't think it'd last very long before our keys are

I'm looking for a message where anyone said we could do this, but we
expect our keys would eventually be blacklisted can you help me out?

I think I'd have said well, you should do that then, put the ball in
Microsoft's court ::shrugs::

devel mailing list

Re: *countable infinities only

2012-06-25 Thread Gregory Maxwell
On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy wrote:
 I'm reading they're going to use a modified Intel efilinux, not writing a new 
 boot loader. And that they will not require either signed kernel or kernel 

Thats my understanding.

 So what's the point of Secure Pre-Boot?

Making Ubuntu work on the hardware people have. Which is the
justification given here why Fedora needed to adopt crytographic
signing of the kernel/drivers/etc.

I think this all would have been a much simpler matter if it wasn't
being described as essential for keeping Fedora operable on the
computers of the common folk.

Of course, users who want more aggressive secureboot would be free to
replace the keys in their system with ones which only sign bootloaders
which are more thoroughly locked down…  but I don't see evidence of
the demand. (can you point to some?)

 I think for at least 9 months now the idea of a strictly pre-boot 
 implementation of Secure Boot is possible, but meaningless to the point of 
 WTF, why bother? with the effort required. It's like building a bridge 
 that's 80% complete, and therefore 100% useless.

And the kernel hands off control to a init/systemd which is unsigned—
which can be rooted and exploit a vulnerable kernel to prevent
updates.  It's like building a bridge that is _10%_ complete, and
therefore 100% useless. :)

… the amount of critical userspace code that runs before updates can
be processed is enormous and the kernel and bootloader is just a tiny
fraction of that.  Why not build the 100% bridge that actually
provides a remotely secured platform? Because it's incompatible with
software freedom. Central control is Microsoft's strength, not
devel mailing list

Re: *countable infinities only

2012-06-25 Thread Gregory Maxwell
On Mon, Jun 25, 2012 at 3:28 PM, Chris Murphy wrote:
 That does not answer the question. Ubuntu would work on Secure Boot hardware 
 if they recommended users disable Secure Boot. So why not recommend that, and 
 not support Secure Boot at all?

I advocated that. It was argued here that this would be an enormous
barrier to usability because common users couldn't figure out how to
do that, doubly so because there would be no consistency in the fancy
GUI UEFI interfaces, and asking people to disable security is likely
to scare them even if we could manage good instructions.

It was also pointed out that some hardware in the future may not allow it.

 So you have located a vulnerability in SELinux or systemd? And you have an 
 exploit example?

Absent those vulnerabilities you don't need secureboot at all.  Just
use SElinux to prevent the userspace from changing the boot
enviroment. The signing only helps if the discretionary access control
is already compromised— it helps you get the horse back in the barn,
but only if enough of the system is protected by it.  In Fedora the
kernel+bootloader isn't enough.  It's a strict subset it helps with.
... I expect this is part of the reason that we've seen no one
requesting this functionality.

Can you point me to a bugzilla entry or even a mailing list post on a
compromise this actually would have blocked, preferably one that
couldn't have been closed without complicating replacing the kernel.

 I observe that this sequence is extremely low signal to noise, poor 
 rationale, and high on derangement.

Derangement. Hm.  Could you actually _feel_ the excellence flowing
through your fingertips as you typed out this message?
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-20 Thread Gregory Maxwell
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald wrote:
 i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp
 this is the wrong perspective
 the right one is the system must not crash if someone does

Good thing it doesn't.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-20 Thread Gregory Maxwell
On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta wrote:
 As a sysadmin...for a multi-seat configuration in a home network I really need to anticipate maximum large file tmp
 usage in calculating my swap partition size for my multi-user family?
 8 gigs of ram... so to be safe I want to set up a swap of what...100
 gigs to account for a potentially large /tmp of some maximum size?

This is an issue you have independent of tmpfs.  How big does / need
to be? (or if /tmp is on another volume due to the fragmentation mess
it creates, how big does that volume need to be).

 Does swap backed tmpfs as /tmp currently jeopardize my system's health
 by making swap backup for in-memory processes compete with tmp files?
 If my users clog up /tmp will that reach a point where the kernel's
 oom process killer decided to start killing off running processes
 instead of throwing crap out of /tmp?

Tmpfs volumes have a size set as a mount option. The default is half
the physical ram (not physical ram plus swap). You can change the size
with a remount. When its full, its full, like any other filesystem

If you set it high enough that you could fill swap and physical ram
with tmpfs plus your workload, then yes, I believe you'd then see the
OOM killer run. I've never had this happen because I've never set my
tmpfs size larger than the available swap I had— so any OOM event
always was due to applications using up too much core.

 What happens when I have 2 users who are both downloading dvd iso
 sized images into /tmp  as well as other things going on. Remind me...
 where does firefox by default cache in progress downloads for the
 Open in facility. Isn't it down in tmp?   Do I really want things
 like firefox downloads paging out ram into swap and causing an overall
 system slowdown?

Yes, Firefox saves to /tmp by default.

Use of tmpfs will not not increase your disk IO. Under that workload I
would expect your DVD data to end up in the swap volume, there is no
adverse performance from this. At least in my experience/measurements
writing out large data to tmpfs has performance equal to or better
than writing out to regular filesystems.

 Without more information about how gracefully /tmp spill over into
 swap is handled, I'm inclined to say this really looks problematic as
 a default.
 And that's not even getting into the more complex issues of virtual
 machine configurations which typically run under heavier ram
 constraints than disk constraints.

It really sounds to me that you're using a ramdisk as a mental model
for tmpfs. That isn't what tmpfs is.  Tmpfs is a filesystem backed by
the kernel's buffer cache, and it can use whatever resources it likes
to back it up.  In practice small short lived things are purely in
ram, while larger long lived data ends up on disk— but it does so at
the kernel's leisure and in a manner which minimizes writes and
latency critical operations.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-20 Thread Gregory Maxwell
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta wrote:
 On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell wrote:
 Tmpfs volumes have a size set as a mount option. The default is half
 the physical ram (not physical ram plus swap). You can change the size
 with a remount. When its full, its full, like any other filesystem

 Okay that was what I was missing. Pegging the tmpfs to some percentage
 of available ram by default.

 Follow up question.. is this value defined at install time or is it
 50% of ram as seen at boot up?
 If I add or remove ram between boot ups, post-install does the tmpfs
 size automatically adjust to 50% of what is available at boot up?

It's 50% available at bootup by default (e.g. this is what you get
when you provide no size option while mounting). I'm not sure what the
systemd stuff is doing, I had the impression it was leaving this as a
default.   I don't know if this is a good thing or not.

On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler wrote:
 I don't think its just a matter of quantity of I/O but _when_ the I/O
 happens.  Instead of the pagecache getting flushed to disk when it is
 convenient for the system (presumably during a lull in I/O) the I/O is
 concentrated when there is a large change in the VM allocations -- which
 makes it very similar to a thrashing situation.

 With a real filesystem behind it, the pages can just be discarded and reused
 when needed (providing they've been flushed) but in the case of tmpfs the
 pages only get flushed to swap when there is memory pressure.

An anticdote is not data, but I've never personally experienced
negative thrashing behavior from high tmpfs usage.  I suppose
thrashing only really happens when there is latency sensitive
competition for the IO, and the kernel must be aggressive enough to
avoid that.

When data is written to file systems normally the bulk will also
remain in the buffer cache for a some span of time until there is
memory pressure.  The difference is how long it can remain (tmpfs has
no mandatory flush) before being backed by disk, how much extra
overhead there is from maintaining metadata (less for tmpfs than
persistent file systems), and how much must be written right away to
keep the fs consistent (none for tmpfs).

On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler wrote:
 So the default is that I can use 2G in /tmp regardless of how much swap is
 present if the system memory size is 4G?  So the only way to get more /tmp
 is to either mess with the max% or buy more ram?

On systems where tmpfs is provisioned for /tmp in fstab you change a
setting to get more space (provide size=fooG mount option).  This is
easier than adding more space to tmp when tmp is on root or some other
file system.

I don't know how it will be set in systemd. Regardless of what systemd
offers you could still toss in an option to remount it with more space
after bootup.

Buying more ram to increase /tmp is silly of course.  The default
behavior is just a default it doesn't imply some kind of cosmic
relationship between your tmpfs size and the amount of physical ram.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-20 Thread Gregory Maxwell
On Wed, Jun 20, 2012 at 4:57 PM, Brian Wheeler wrote:
 But in any case the I/O advantages have never been shown, despite multiple
 requests by myself and others.

I posted some example numbers earlier in this thread.  e.g. make on an
already compiled firefox source was half the time on tmpfs compared to
ext4— even though the workload was all hot cache. Also its easy to
observe the write activity on tmp that happens even for short lived
files and reducing write load on SSDs was one of the main arguments
advanced for this change.

 Well, yes and no. You also have to make sure you have enough backing swap or
 you're screwing yourself out of usable ram.

Yes, and the installer does this IIRC.

 The problem here is that the
 amount of /tmp by default is small by default so the tinkering with sizes is
 actually more likely to be required that it was before.

Yes, this was why I said I didn't know if it was a good idea that
systemd leaves the default alone or not.  I don't run any of my
systems that way.

If this change turns out to be problematic then I think this would be why.

 Maybe for F19 I'll submit a feature that requires all X apps have to use
 8-bit color (oooh, and private colormaps) since its will make network
 rendering 3x faster and that what solaris used to do!  Don't ask any
 questions, though, because you can't possibly understand and I know it just
 works for me.

You should just remove network transparency from the window system
entirely. No one needs that and besides VNC/Spice is good enough for

devel mailing list

Re: *countable infinities only

2012-06-19 Thread Gregory Maxwell
On Tue, Jun 19, 2012 at 11:50 AM, Eric Smith wrote:
 If the things that make it difficult to run software of your choosing on a
 device can be proven to serve no purpose but to stifle competition, then
 yes.  But often those things have other purposes as well.  For example,
 requiring firmware updates to be signed has a demonstrable purpose in
 preventing certain types of malware from infecting a product, so that
 feature cannot be said to serve no purpose other but to stifle competition.

Though it serves a genuine interest it is not, however, a least
restrictive means.
(at least not when it inhibits the user completely)

It wouldn't pass the tests we'd apply if it were a state mandated restriction,
should the fact that it's not actually a state restriction matter though when
it has market force equal to the state's authority?  Seems kind of funny
that in the US we've been so careful to avoid the state infringing individual
rights and then somewhat careless about other powerful entities using
massive money, state granted monopolies, and market force to achieve
the same ends.  It's a mad world. ::shrugs::

One thing we can do is not license our code for these environments that
deny users these freedoms. If we think that restrictions on freedom by
private parties is an acceptable risk where it wouldn't be acceptable
for the government because market solutions work against private
parties then we have to do what we can to make the market solutions
work.  Part of that means that we should stop giving them free
software for use in products where they deny users the same freedoms
they enjoyed.

RedHat and Fedora participating in this technical process which denies
freedom to users will simply make the issue harder to address via the
market because will make drawing the lines between acceptable and
unacceptable behavior harder, potentially resulting in another billion
dollar company on the unacceptable side of the line— an outcome
which no one wants— and it will undermine the arguments people
would make for state intervention, since the antitrust arguments
are rather fragile and courts are unlikely to appreciate the nuance
of why RedHat and only RedHat (for an extreme example) being
able to ship GNU/Linux for popular desktops doesn't disprove
competitive concerns.
devel mailing list

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-18 Thread Gregory Maxwell
On Mon, Jun 18, 2012 at 12:09 PM, Lennart Poettering wrote:
 I mean, have you ever tried to upgrade firefox while running firefox? If
 you did, you know how awfully wrong that goes... [1]

I run Mozilla's nightly builds and receive updates every day. They
disrupt nothing because Mozilla has built infrastructure to make that
possible. Firefox must be restarted for the updates to take effect,
which is when it does the actual swapout of the staged files, but the
restart is basically just a window flickering— tabs retain their
state, including forms— in fact to prove the point I manually
triggered it while writing this email.

This is the direction Fedora should be heading in, if not quite as
non-disruptive as what firefox does... and it's not that far off
because with the exception of the recently written desktop
infrastructure the system largely already support non-disruptive
updates. By making updates regularly require reboots the incentive to
bridge the gap is reduced and the expectations of a clean enviroment
will increase until a rebootless update is as inconceivable in Fedora
as it is in Windows.

By making updates regularly require reboots you put users in an
adversarial relationship with updates. Rather than being seen as
something that helps them, updates will be seen as something that get
in their way. Many will turn them off completely if you give them an
option to do so.  We don't have to speculate about the long term
consequences of this path because we can already see it in the Windows
world: e.g. On several occasions I have seen windows update disrupt
presentations because the speaker was talking to the audience and
didn't react fast enough to the snooze button on the mandatory updates
they've been deferring.
devel mailing list

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-18 Thread Gregory Maxwell
On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating wrote:
 On 06/18/2012 09:24 AM, Gregory Maxwell wrote:
 I run Mozilla's nightly builds and receive updates every day. They
 disrupt nothing because Mozilla has built infrastructure to make that
 possible. Firefox must be restarted for the updates to take effect,
 which is when it does the actual swapout of the staged files, but the
 restart is basically just a window flickering— tabs retain their
 state, including forms— in fact to prove the point I manually
 triggered it while writing this email.
 Your anecdata does not match my anecdata.  Both Firefox and Thunderbird will
 malfunction in strange and subtle ways if the package is while the
 application is running.  A restart of the application is required before
 things start behaving as expected.  There are enough people out there
 experiencing this that one cannot wave it off as hallucinations.  It is a
 real problem that exists despite your experience to the opposite.

I'm not waving it off.  It's something which Mozilla has fixed in
their nightly update process which is not addressed in Fedora updates
for Firefox.  Mozilla nightly pre-stages the update and then does the
update on startup.  When combined with persisting the application
state across restarts it makes the whole thing painless.  Otherwise,
yes, it can be problematic, as firefox does runtime dlopening and such
and can end up inconsistent if you swap out files out from under it.
devel mailing list

Re: *countable infinities only

2012-06-18 Thread Gregory Maxwell
On Mon, Jun 18, 2012 at 3:15 PM, Chris Murphy wrote:
 On Jun 18, 2012, at 10:05 AM, Matthew Garrett wrote:
 2) Government. If a large enough set of national governments required
 that secure boot be disabled by default then we could assume that
 arbitrary hardware would work out of the box. It's unclear to me which
 laws you think the vendors would be breaking, but I'm not a lawyer.

 In the current U.S. (and likely EU as well) political climate, i.e. extreme 
 ignorance of computing, fear of real and imaginary infrastructure 
 vulnerabilities, and desire to make out with all things with the word 
 security, there is in my estimation no chance Secure Boot nor the Windows 8 
 hardware requirements will be perceived as being anti-competitive.

Certainly if you subtract Microsoft's desktop monopoly from the
equation the more likely legislative direction would be towards
_mandating_ secure boot, without user installable keys, in products
sold or marketed in the US just like we see with video recorders and
macrovision.  Or at least, that probably wouldn't be a tremendously
uphill battle for someone who wanted to lobby for it, precisely
because of the climate you've outlined.

The implication that such legislation was a bought and paid for
outright land-grab market over to monopolists would probably be the
only effective argument against it— because everyone is blinded by
words like cybersecurity, so arguing that we don't need to take
user's control of their computers away for cybersecurity won't work,
and varrious narrow exceptions for research and education will
silence the majority of the special interests who would otherwise

Part of the reasons that emotions can run high here is that this is
all happening in the context of a general change in computing devices
with long term human right implications, issues far beyond the ease of
installing a single distribution. As software mediation becomes more
critical in people's lives control over that software is being further
restricted. Can free software survive as something that preserves
individual rights as it becomes increasingly beholden to large
publicly traded companies for basic usability?  As technically skilled
people we're all taking part in building the future— but what future
will it be?

Hopefully not this one:
devel mailing list

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-18 Thread Gregory Maxwell
On Mon, Jun 18, 2012 at 4:53 PM, Lennart Poettering wrote:
 Well, even if Mozilla fixed that, such a solution wouldn't work for OS
 updates, already due to privilege reasons. i.e. pre-staging changes as
 root which are applied when a user does something simply cannot work if
 you care about security or supporting multi-user systems.

Cannot is a strong word.  For example, an update process can hang
around and watch for all instances process to go away while some
notification facility nags users to restarted.  Or on close the DE can
signal the staged upgrade to go through, or just automatic on reboot.

Reboots on triggered from the desktop environment certainly no more
multi-user hostile than that.
devel mailing list

Re: *countable infinities only

2012-06-18 Thread Gregory Maxwell
On Mon, Jun 18, 2012 at 4:45 PM, Adam Williamson wrote:
 What I should have said is that we have no God-given right to demand
 that any computing device offered for sale must be explicitly designed
 to accommodate the retrofitting of other operating systems or software,
 or indeed to demand that any device available not be designed expressly
 to prevent it. What I was trying to correct was an impulse to assume
 that the x86/BIOS world where systems are explicitly designed to make
 execution of arbitrary code easy is the One True Way for things to be,
 rather than an accident of history, and anyone doing anything different
 must inevitably be guilty of some kind of crime or immorality and must
 be fought to the last ditch.

Indeed the laws and norms of our societies do not currently mandate
a right for devices to be easily modified by the users.

But the copyleft licenses that free software are distributed under do
require that kind of freedom be not removed via copyright as a condition
for distribution of the copylefted work because the freedom to modify the
software we use is something important and worth investing resources
into maintaining for everyone, even if it doesn't quite rise to the level of a
recognized human right. It's also the case that making sure all the users
have good access to become authors keeps the ecosystem viable and
that the participants have standing which is legally equal makes it fair
(well, as fair as anything can be... not always very).

And with the trend of software systems mediating an increasingly
large portion of our public and private lives, I think we will be fools
if we don't recognize some degree of software freedom as a human
right someday— at least if there is any remaining question of it
being denied.

We can split hairs over the current technicalities, but copyleft licenses
were created so that people could give away software without downstream
users enhancing it and locking it up again using copyright. If, practically,
technologies like secureboot and trusted boot produce the same result
through cryptographic lockdown instead of the threat of copyright
litigation then anyone who rationally choses to use copyleft would
choose to prohibit those things too.  After all, cryptographic signing
that actively prohibits users is a far more practical issue then the
threat of copyright violation litigation.

It will be unfortunate to see Fedora and Redhat in a position of arguing
against licensing that allows authors to ensure that their work isn't used
as a part of systems that deny their recipients the intended freedoms,
simply because fedora has become invested in working with the
freedom denying infrastructure— or even profits directly from it if
'competition' with radically open development practices find that they're
structurally or philosophically unable to comply with the requirements for
obtaining an automatically accepted signing key.

And keep in mind: Fedora 18 with the signed bootloader will work fine
on systems which do not permit the owner of the system to change the
keys— while this might not be the world that exists when UEFI initially
ships there is no assurance that it won't be later, and the decision to
sign now is one less argument (if only a small one) against removing
the option, and as was noted by others here at least some of the
OEMs would apparently really like to do that.
devel mailing list

Re: *countable infinities only

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 12:51 PM, Chris Murphy wrote:
 It was justified. Only one is speculation. The other utilizes evidence and a 
 track record of behavior.

... Right,  In one case the actual participants in the discussion have
expressed doubt that they had any effect, and in the other we have a
company which has been previously convinced multiple times in multiple
jurisdictions of unlawfully using their market force in the desktop
space to suppress competition.

I think it's all worthless speculation. But the alternative worthless
speculation I offered is the one backed by a track record.

 I certainly have not done this and by using this argument against me

 You're paranoid. Are you a handful of people?

I'm the person you were responding to and quoting.  If you weren't
trying to smear me with those claims why did you bother including
them, am I to believe it was just an observation on the weather?

And again, here you are with the emotionally laden accusations of poor
mental health.  Paranoid, and later you continue with undirected
criticisms towards conspiracy theorists. I'm sure if I ask you to
substantiate where any argument I've made has justified dismissal with
that label you'd again respond that it had nothing to do with me and
that I was being paranoid for suspecting that your comments in a
message directed to me, quoting my message, and otherwise generally
appearing to respond to me actually had anything to do with anything
I've written in the slightest.

 And repeating yourself is going to get you a different answer than you've 
 already gotten, naturally. It couldn't possibly be that the argument is 
 inapplicable or uncompelling.

Except it hasn't gotten an answer. I assume because there is nothing
really to answer. As far as I can tell simply a matter of fact that
the cryptographic lockdown will not meaningfully increase security for
Fedora users.  Perhaps it'll make for a nice bit of security-theater
marketing, but the actual malware authors will not be deterred by it
because controlling the boot sector isn't a goal of malware, it's a
means and there are plenty of more or less equally good means to the
same end which are left exposed.

 The Windows 8 certification is the most significant change in Microsoft's 
 hardware requirements ever, as far as I can tell. It's a significant 
 departure from their support legacy at most any cost position prior to 
 this. Clearly they are more than a bit concerned about boot loader malware 
 than they are gaining, what, 1%, by obliterating the entirety of desktop 
 Linux with this conspiracy.
 Old hardware that doesn't meet the Windows 8 hardware requirements can't 
 claim to be made for Windows 8. If a vendor wants that certification and logo 
 usage as an OEM, they have to meet the requirements for that certification. 
 Simple. I'm only opining that those requirements represent the most 
 aggressive change I've seen from Microsoft to date.

Old hardware that didn't meet the Window XP logo requirements couldn't
claim to be made for Windows at that time.  I couldn't judge if this
was an more than typically aggressive change or not— I'll take your
word for it— but you claimed that there was a significant departure
from support legacy at most any cost, and I'm not seeing it.

 I therefore further opine conspiracy theorists necessarily have to believe 
 that the conspiracy is primarily to obliterate a ~1% market, and that this 
 piddly market is a greater concern to Microsoft than boot loader malware, or 
 face planting with Windows 8, Metro, Windows Phone 7.x, 8.x, RT, or their

I've never said nor thought that.  As far as I can tell it's a move to
achieve greater and more consistent control of the whole platform in
order to extract greater revenues from add-ons (things like Media
center pack), gain access to additional revenue streams (Metro app
store), and provide a user experience more competitive with Apple's
(not gunked up with crazy drivers added by every intermediary the
system goes through).   If it also suppresses some Linux along the
way, thats actually an unfortunate outcome— Microsoft is already being
paid for Windows for those systems, and anti-competitive behavior
invites unwelcome regulatory scrutiny.

... and so what?  That fact that it's almost certainly not all some
diabolical plan doesn't make the resulting inequality it generates
between RedHat and it's upstream and downstreams any more justifiable.
devel mailing list

Re: *countable infinities only

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 1:25 PM, Reindl Harald wrote:
 you are aware that on ARM platform is NO DISABLE SECURE BOOT allowed
 this is not future requirement
 this is CURRENT requirement for Win8 on ARM

It was also the original requirement on x86 before negative PR was
generated and the requirements were changed.

I'm not sure if it will actually happen on x86 too, I'd give it less
than even odds only because the push-back from people who refuse to
believe it can't happen may well keep it away, but it seems really
weird to dismiss this as a far out concern.
devel mailing list

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes wrote:
 That's simply not possible. Some processes like dbus-daemon and
 gnome-session just cannot be restarted in this way. It's a complete
 fallacy to believe you can update core libraries on a modern Linux
 system without rebooting.

I upgraded running systems from a.out to elf and from libc to glibc
without shutting down.

Okay, init itself is a bit tricky, but it also basically does nothing
on a running system so the problems in upgrading it are not especially

And now some mere userspace daemons mean users will constantly need to
reboot for upgrades?

Regressions against featuresets from the '70s and '80s are pretty unfortunate.

This is starting to sound like evidence of a serious design flaw in
some of these daemons. I find that unfortunate because I really like

(And the you can manually force it, seems not much of a consolation
to me— since that will be untested, unsupported, and very likely

If we ask the question— retrospectively, if we knew that eventually
the acceptance of systemd (or newer dbus-daemon) would have ultimately
resulted in needing to reboot for updates would we have accepted it?
I think the answer is pretty clearly No.

If slippery slope arguments are to be dismissed when they're used
against new features like systemd (or Wayland or whatever), then
Fedora really does need to draw a line in the sand and say no to bad
effects when they crop up.
devel mailing list

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 2:08 PM, drago01 wrote:
 A new feature is being added nothing is getting removed so no there is
 no regression.

Thats newspeak if I ever saw any.

Going from a system which generally doesn't prompt users to reboot to
one that does is a regression.

 dbus is not optional. Not including it would mean throw out half of the 
 And no idea what that has to do with systemd either.

 Randomly blame stuff does not help your point.

I was not randomly blaming I was copying from Richard Hughes
message.  He said these services need system reboots for upgrades.
That isn't what we signed up for

 I am not seeing any bad effects here ... I am seeing a feature
 proposal that tries to solve a problem that you dismiss as non
 existent while it is.

I haven't personally experienced problems with this but I trust that
there are problems.  Causing users to need to reboot for updates does
not solve the problem— it masks it.  And masking can be a fine
solution where its harmless, but it certainly isn't here.  The
reboot for upgrades stuff in windows is one of the most often cited
annoying anti-features, so it's understandable why people would throw
stones at something that looked like it was emulating it.
devel mailing list

Re: *countable infinities only

2012-06-16 Thread Gregory Maxwell
On Sat, Jun 16, 2012 at 7:14 PM, Chris Murphy wrote:
 Ahh, the Ostrich Maneuver.

 Had this been the policy of others working on this issue, Microsoft would
 not have updated their Windows 8 certification to require the user be able
 to disable Secure Boot. And then we'd all be in a significantly worse
 position. So congratulations on locating a really hideously bad idea, one
 that actually supports the original Microsoft position.

Or, perhaps, they would have found themselves behind the gun-sights of
the DOJ again and dropped the whole thing in order to avoid years of
costly antitrust litigation.  (Or do you think they would have backed
off at all, just because someone asked, if they didn't think that risk
was at least somewhat credible?)

Hypotheticals are like that. Who knows?

Certainly people who are of the opinion that Fedora shouldn't run on
devices that need signed kernels aren't going to be convinced that
gaining the ability to make that choice was a big improvement.
devel mailing list

Re: *countable infinities only

2012-06-16 Thread Gregory Maxwell
On Sat, Jun 16, 2012 at 8:16 PM, Chris Murphy wrote:
 Calls for speculation. We know what the certification policy used to be. We 
 also know how long DOJ takes to do anything, let alone politicking behind the 
 scenes to arrive at compromise, let alone its day in court. Years. 
 Generations of computers without a disable feature.

Good job selectively quoting the part of my message where I was saying
that it was a call for speculation either way.

 This handful are the people who use adversarial words like: fight, war, 
 battle, attack, surrender, engagement, tactical, etc. to describe this topic. 
 This verbiage is the hallmark of propaganda, designed to cause emotive 
 reactions in people, so they don't consider inconvenient things like facts.

I certainly have not done this and by using this argument against me I
feel you're guilty of the same:  It appears to me that you're
suggesting that I'm somehow asscoiated with propaganda (an
emotionally laden word too) and that people should not bother with an
inconvenient thing like contemplating my position.

 Oh, the same people who must think boot loader malware is somewhere in the 
 continuum of people's imaginations to being exclusively a Windows threat.

Except, as I argued early in these thread, for Fedora the
cryptographic lockdown will not meaningfully inhibit boot _time_
malware.  If malware can exploit your kernel to infect the bootloader
so that the kernel rootkit is reinstalled at every boot to prevent
updates from removing it then it can just as well infect systemd to
the exact same end.  It only helps if the whole system runs no
unsigned code at least upto the point where it connects to the
internet and gets updates.

There are a great many things Fedora could do which would have clear
security benefit without the compromises. Where is the effort to fully
seccomp-2 restrict and/or SELinux lockdown every use app that handles
hostile network input, for example.   Closing the door on botnet
software long after the machine is compromised is a pretty weak
security feature and thats the most the signed bootloader/kernel can
offer, and even that requires signing up half the userspace too.

 The Windows 8 certification is the most significant change in Microsoft's 
 hardware requirements ever, as far as I can tell. It's a significant 
 departure from their support legacy at most any cost position prior to 
 this. Clearly they are more than a bit concerned about boot loader malware 
 than they are gaining, what, 1%, by obliterating the entirety of desktop 
 Linux with this conspiracy.

Old hardware will continue to run Windows 8. I don't see that I've
seen any evidence of Microsoft adopting policy to ensure that new
hardware would continue to run Windows, are you saying they have?
devel mailing list

Re: *countable infinities only

2012-06-12 Thread Gregory Maxwell
On Tue, Jun 12, 2012 at 10:22 AM, Peter Jones wrote:
 This seems like a pretty unlikely scenario. You have to disable secure boot
 to perform most kernel-level debugging operations in Windows 8. It'd
 pretty much the entire OEM community for Windows add-on card drivers, pretty
 much all major enterprise customers, and all computer science departments
 use windows for any OS program, just as some examples. Microsoft knows it
 needs these people.

One way to tell if the characteristics you know about something are meaningful
is to replace the thing you're talking about and see if the comments make any
less sense.

You could replace disable-secure-boot with access to source code here and
it makes absolutely as much sense except for the fact that they don't generally
give access to their source code.

Certainly as a developer it's even more important to be able to read the
implementations of the stuff you're calling than it is to be able to run
modified versions of them.  Presumably if Microsoft manages to get
by with giving drivers authors highly confined access to implementation
details they could get by just as well requiring people to sign up to buy
developer cryptographic keys in order to do kernel debugging.

Alternatively you could make the same arguments about various mobile
platforms which are normally shipped to users in a totally locked down
state: the hardware peripheral makers need low level access. The vendors
manage to find ways to accommodate these people without compromising
their control over the normal installed base.
devel mailing list

Re: *countable infinities only

2012-06-12 Thread Gregory Maxwell
On Tue, Jun 12, 2012 at 12:25 PM, Adam Williamson wrote:
 You are, and that was being very un-excellent, so please refrain from it
 in future.

I'm left wondering where your concern about being excellent to each
other has been hiding throughout this thread, and where it was when
you made the Your Majesty comment to Jay Sulzberger moments after
this post.

 It is never a good idea to assume malice where you can't prove it.

This sounds like a guilty conscience speaking to me. I never claimed
any malice.  I apologize if my message sounded as though I were.

Let me make this more clear:  People in this thread have been saying
that instructions can't be created because the hardware is not
available to the public yet.  However, the people working this stuff
actually do have access to UEFI secureboot hardware. I presumed this
was under NDA, because none of them were stepping up to say no,
actually I do have the hardware.

The idea that the firmware is complete enough to build and test the
cryptographic lockdown but not complete enough to make write
instructions against simply didn't occur to me.   And with that
thought in mind I think it's even more sad that the Fedora community
isn't focusing primarily on making instructions _now_ while there may
still be an opportunity to encourage making those yet unwritten
interfaces easy and consistent.
devel mailing list

Re: *countable infinities only

2012-06-12 Thread Gregory Maxwell
On Tue, Jun 12, 2012 at 1:43 PM, Bill Nottingham wrote:
 No offense, but you seem to have a very unusual idea about how much leverage
 Fedora has anywhere. Why would hardware vendors listen to a community
 distribution that they never preinstall, have no plans to preinstall, and
 brings them absolutely no money?

MJG was saying that (some?) vendors were willing/interested to install
a Fedora/Redhat key but that the belief was that leveraging the MSFT
process a better outcome due to the cost of running an equivalent
service to MSFT's.


How can we know our strength if we do not try?
devel mailing list

Re: *countable infinities only

2012-06-12 Thread Gregory Maxwell
On Tue, Jun 12, 2012 at 1:59 PM, Peter Jones wrote:
 Quit trying to have it both ways, Greg. If we get vendors to let us ship a
 Red Hat key - and to be clear, it was a *Red Hat* key that's been offered
 to be shipped - then we're putting forked projects and stuff in a
 significantly worse position. This is no put up $99 and you're in, it's
 become a market leader and develop contacts at each vendor and maybe they'll
 be nice to you.

 That's *far* worse for free software.


The text I was responding to was:
Why would hardware vendors listen to a community distribution that
they never preinstall, have no plans to preinstall, and brings them
absolutely no money?

And my point was that if they're willing to add a RedHat key then
their willingness to listen— at least to some extent— isn't even up
for debate!

Of course a RedGat key wouldn't be an improvement at all, I apologize
for being unclear.— Though, frankly, as far as I can tell it would
only be worse from a cost and RedHat PR perspective, since we'd lose
the distraction of MSFT as a boogieman here, but I see no reason to
debate that because it would be just as bad as far as I'm concerned.
I was just arguing that we do have some amount of vendor attention
here,  and we don't know how far we could get with that and with
public support unless we tried.
devel mailing list

Re: *countable infinities only

2012-06-12 Thread Gregory Maxwell
On Tue, Jun 12, 2012 at 2:27 PM, Peter Jones wrote:
 No, they literally cannot do that. Having a special debugging key that
 chains to a CA key that's in the key database (DB), which would allow the
 ability to do kernel debugging activities which could, for example, write
 to arbitrary memory, would completely obviate the ability of Secure Boot
 to be effective at all.

 The scenario you describe /cannot/ work.

Here is one fairly simple way, as an example— When you register as a
developer with Microsoft you run a tool on the your target system to
extract the trusted boot identity and they return to you signed
certificate that says this particular piece of hardware is allowed to
boot unconfined.  You give this certificate to your Secure Boot signed
bootloader and it lets you choose to boot an unprotected debugging
enabled kernel— but only on the hardware you've registered.

Because many though not all systems shipping _now_ are trusted boot
compatible I expect this to be even more true in the post UEFI world.
Developers haven't found needing special hardware for hardware
virtualization to be a big deal, so requiring TXT extensions doesn't
sound like much more to me.

There are also many other less good options, e.g. requiring special
developer hardware as has been done at times in the mobile space,  but
I don't really need to invoke them because the standard commodity
hardware will have all the required components if not in the
immediately coming generation then in the next product cycle.  There
is nothing contrived in this argument— executing this kind of control,
for good or bad purposes, is exactly what this technology is being
developed for.

(And, of course, Microsoft has been using signed drivers for some
time— at least partially because the ecosystem around windows has been
a bit too free wheeling for their tastes and ability to support)

The notion that locking down the systems is incompatible with enabling
(at least some kinds of) development is simply disproven by the
vigorous development we see on locked down devices. As as been argued
here to excuse the lockdown of Fedora, developers are often willing
and able to take some additional steps— especially in the context of
commercial development for the worlds most popular platform.
devel mailing list

Re: *countable infinities only

2012-06-11 Thread Gregory Maxwell
On Mon, Jun 11, 2012 at 9:56 AM, Nicu Buculei wrote:
 Of course we are missing that part *now*, there is no motherboard with UEFI
 and Secure Boot in the wild so we can take screenshots and publish them.
 Once such board will be released, plenty of instructions and tutorials will
 follow, to make it work not only with Linux, but also with older versions of

My understanding is that the folks working on secureboot are too busy
building cryptographically signed boot-loaders that will inhibit users
from changing their kernels to take pictures and work on instructions.
 But I could be mistaken.
devel mailing list

Re: *countable infinities only

2012-06-04 Thread Gregory Maxwell
On Sun, Jun 3, 2012 at 10:11 AM, Peter Jones wrote:
 On 06/02/2012 05:47 PM, Gregory Maxwell wrote:
 There is no additional security provided by the feature as so far
 described—only security theater.   So I can't modify the kernel or
 bootloader, great—but the kernel wouldn't have let me do that in the
 first place unless it had an exploit. So I just put my rootkit inside
 systemd so that it executes the kernel exploit right after reboot, and
 the exploited kernel now silently keeps updates from being applied.

 You've sortof missed the point. A privilege escalation exploit, currently,
 can sabotage your bootloader, insert its own ahead of it, and modify the
 kernel to perpetually hide itself. Right now such exploits are generally
 bounded by selinux, which would, in most cases, stop them from performing
 the systemd trick that you describe. At that point it has escalated past
 the point where it's confined by selinux or anything else, and can do your
 trick and far worse.

 And again, there *are* bootkit exploits in the wild now. So any argument
 that there's no legitimate security benefit to securing the bootloader is
 prima facie false.

It's the goal that matters. Not the method. The attacker wants
persistent control of the system which can't be fixed by updates.
Replacing the kernel/bootloader is just one of many possible means to
achieve this end.

With signing, yes, replacing the bootloader doesn't work because
doing so will brick the machine.  But it doesn't matter, because
replacing systemd is in no way worse for the attacker than replacing
the bootloader in most situations where they would have been able to
replace the bootloader.

So two possible situations: kernel security works completely and there
is no privileged escalation exploit strong enough to defeat the kernel
imposed security— in which case you don't need any boot time
cryptographic lockdown because the kernel can simply deny the ability
to rewrite the kernel/bootloader,  or it's possible that kernel
security is buggy, in which case, the attacker doesn't really have to
care about the boot-time cryptographic lockdown because he can just
make systemd run the exploit code again at every boot— which would
accomplish the attackers goals just as well as replacing the

The case where it would matter is where the attacker can bypass kernel
security and raw-write to the disk, but can not write to kernel memory
or execute arbitrary code as the kernel or replace the update process
with a fake one... which seems really narrow to me. Not to mention the
disinterest in this as a feature is demonstrated by the fact that
while we could have officially supported inhibiting root from writing
to disk (and accessing kernel memory in order to allow them to
escalate to raw-disk-writing) which would be 100% as effective as
boot-time cryptographic lockdown, absent kernel bugs, but we haven't
and there is no public evidence (as far as I can tell) of Fedora users
asking for it.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 5:32 AM, drago01 wrote:
 Or you don't do the later and just disable secureboot. Your freedom is
 in *no way* limited by having secureboot support.
 Let me repeat it again supporting secureboot on x86 does *NOT* limit
 your freedom.

After all this discussion you'll still make that claim?  I feel insulted.

When I create a fork, respin, or remix of Fedora and distribute it to
people it will not run for them like Fedora does without a level of
fiddling which the people advocating this have made clear is entirely
unacceptable.  This is because Fedora will be cryptographically
signing the distribution with keys these systems require and not
sharing the keys with me.  Fedora be doing this even with software
that I wrote, enhancing it with a signing key only they have access
too, making it much more useful on hardware where it is not otherwise,
and not allowing me and or downstream recipients to enjoy the same
improvements for their modified versions.

What is unclear about this?

Let me offer this in the form of a question:   Why don't Fedora
developers just disable SecureBoot on their own systems and not bother
implementing anything with it in the distribution?
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 12:04 PM, Chris Adams wrote:
 Once upon a time, Gregory Maxwell said:
 When I create a fork, respin, or remix of Fedora and distribute it to
 people it will not run for them like Fedora does without a level of
 fiddling which the people advocating this have made clear is entirely

 As I understand how this works, respins/remixes of Fedora that use the
 Fedora boot loader shim, Fedora grub, and Fedora kernel will still be
 signed and work with Secure Boot enabled.

You can use the fedora signature as long as you don't modify the
software (such as replace the kernel with a realtime kernel for
multimedia use— which is actually the only reason I've ever had to
distribute modified fedora kernel myself).

(An interesting question there is will the signatures end up covering
anything with fedora trademark branding)

 I don't like Secure Boot being forced upon us, but we don't have any
 real choice in the matter; vendors _are_ going to implement it.  Fedora
 certainly doesn't have sufficient market share to get everybody to

I wasn't making that argument there—  though I think it's still a
worthwhile one to have—  only pointing out that this is a material
loss of freedom. You can argue that there is an unavoidable compromise
here and that this is the best option we have by far, and I won't feel
like you are misunderstanding my position.

On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote:
 You do realize that if you create a fork, respin, or remix that you will
 have packages on the system that are not signed by Fedora's GPG key, and
 your generated ISOs will not be signed by Fedora's GPG key?  Worse, there is

Which is irrelevant because there is no hardware that Fedora needs to
used these keys to gain access to.

 (Users would have to disable
 yum's gpg checking in order to install your unsigned package, or they would
 have to install /your/ gpg key and trust it in order to install the package
 signed with your key).

I distribute modified copies of Fedora's OpenSSL libraries, they're
signed my by key not Fedora's.  Users— even rather technically
unsophisticated— install them without any difficulty.  The install
tools do not enforce that the files be signed, they do not have to
install my key.

Try for yourself, if you like:

 You have as
 much equal footing as Fedora does to plunk down the $99 and play along in
 the PC sandbox.

So if I were to take, say, a GPLed compositing window manager and then
I paid $99 for a license to embed a copy of commercial opengl special
effects— which prohibited modification, reverse engineering,
redistribution by unlicensed parties, and commercial use—  then I
started distributing this modified version... and I gave it to you and
told you that you were free to pay $99 to play in the
graphically-enhanced distribution sandbox,   you'd think that was

I'd like to now summon the folks arguing for this who earlier insisted
that Fedora was being upfront about the tradeoffs here to come argue
with people that there isn't a material loss of freedom.  Being
upfront means not only speaking up for points that support your
devel mailing list

Re: Action required: Rawhide: /tmp is now on tmpfs

2012-06-02 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 10:28 PM, Reindl Harald wrote:
 it does not matter WHAT get swapped out
 from the moment on the system starts to swap performance sucks

This is what I meant about being dogmatic up thread.  You're being a
anti-swap zealot here.

Yes, using swap is slow. It's slow because using the disk is slow.

If you are using the disk because tmpfs is being written out, or
because your tmpfs is just a file system is the same thing.

Tmpfs just has the advantage of minimizing the disk activity— both in
cases where none is needed, and in cases where it is.

Really, you should try it.  It works very well and does not make your
machine perform poorly, even when under memory pressure.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 12:36 PM, Matthew Garrett wrote:
 Per spec the machine simply falls back to attempting to execute the next
 entry in the boot list. An implementation may provide some feedback that
 that's the case, but there's no requirement for it to do so, so it's
 perfectly valid for it to just fall back to booting Windows with no

If the issue were just the opaque and unpredictable behavior on
failure this could be addressed without signing any of the
distribution proper.

Create a pre-bootloder.  If secureboot is enabled only permitting this
boot because it's signed with the msft key,  then display the most
helpful instructions WRT secureboot we can display and then halt.   If
secureboot is not enabled, pass control to grub.

This should meet the signing requirements and it removes the opacity
without locking down any of Fedora.  Such a bootloader should meet
whatever requirements to get signed, since if secureboot is turned on
it wont boot anything at all.

I strongly encourage this mode to be created and included with Fedora
even if goes down the route of locking down the operating system... so
when people do replace their bootloaders/kernels they're not just
stuck booting into windows or getting a black screen.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 4:02 PM, Matthew Garrett wrote:
 On Sat, Jun 02, 2012 at 03:28:03PM -0400, Gregory Maxwell wrote:

 This should meet the signing requirements and it removes the opacity
 without locking down any of Fedora.  Such a bootloader should meet
 whatever requirements to get signed, since if secureboot is turned on
 it wont boot anything at all.

 But you're happy to sacrifice the freedom for people to modify the error
 text that's provided? What's your threshold?

I'm not quite sure where my threshold is, I'd have to think really hard on that.

But I don't have to think hard about this particular example, because
wherever the threshold a program that just displays a help screen on
how to disable the restriction is on the least troublesome extreme of
the continuum.

In particular, I can just conclude that this bootloader is not free
software. And that including a small piece of non-free-software that
simply serves the purpose of helping the user figure out how to permit
installing free software is unfortunate but is strictly less bad than
the blobby firmware Fedora already ships.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 4:21 PM, Matthew Garrett wrote:
 That's fine as long as you speak English.

Come on now, you're building a strawman argument. I never said that it
had to be in a single language—notice messages I _normally_ write get
put into many languages.

I don't see why the text of the screen couldn't be outside the signed
area so people could continue to develop it in an efficient manner.

 But you've arbitrarily decided that the
 freedom to do anything about that isn't one that you care about? There
 are no easy answers here. You've just drawn your This freedom is
 worthwhile line in a slightly different place to me.

There isn't an easy answer here because you've defined a higher goal
then just getting information to people.

The goal you've set—Fedora working out of the box on this hardware
without user fuss—can't be accomplished via technical means, except by
restricting the bootloader and kernel.  There is no law of nature
which says that this must be your goal, however.

When it comes down to it, your drawing the line argument just
doesn't make sense.  There is always injustice in the world.  If you
want to be pedantic, anyone who ever seeks a more lawful or more
ethical path is simply drawing a line, because there is always some
more fundamental injustice they've left unsolved for the moment.

We have an operating system where the users can modify it—top to
bottom—and distribute the results, and have them just as able to be
used as Fedora itself is, where they all stand sharing with each other
as technological equals without having to ask permission.  This
freedom is both an ethical stance, embodied in the vision of the
Fedora project and in the licenses of the many thousands of free
software packages Fedora ships, and also a competitive advantage,
because this kind of freedom is precluded by the the business models
of Apple and Microsoft.

This isn't just the practical advantage of being able to twiddle with
our own machines, but also the advantage of having a cooperative
ecosystem rather than a co-opting ecosystem.  But with this change,
for the majority of users, Fedora will become a lot more like
Microsoft's offering—a locked kernel which you can load userspace apps
on top of— which you can jailbreak to get more freedom. This is
practically a twenty-year step backwards in software freedom, a loss
of a practical advantage of our software, and an affront to the
developers of copylefted software—some written as a direct attack on
these kinds of restrictions. And it is the loss of a strong principled
position which we have used to market free software: that the concept
of jailbreaking is foreign to us because we don't, as a matter of
principle and of license compliance, restrict our users.

There are places where the freedoms provided by Fedora have practical
limits—and in those places we find people arguing to advance those
causes (such as preemptively renaming trademarked packages). But that
in no way excuses a new loss of freedom; if it is to be justified, it
must stand on its own merits. These merits must be judged not against
the weakest strawmen, but against the best alternatives. A signed help
screen is an alternative.

Fedora installs are easier than they were ten years ago when you did
have to frequently mess with the BIOS—and where the failures never had
a nice help screen—but being realistic, our install instructions still
have people raw-writing images to usb sticks, and it is still not that
uncommon to have to muck around in the BIOS to get the boot order
right. A totally clueless person with an install disk can easily wipe
out a system full of their data.  I think regressing to the installs
being somewhat easier than ten yearsish ago is still a better place to
be than the cryptographic lockdown.

Why not try the half step— a restricted help screen display module—
and only go the whole way if it proves inadequate?
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 5:26 PM, drago01 wrote:
 On Sat, Jun 2, 2012 at 11:14 PM, Gregory Maxwell wrote:
 I think regressing to the installs
 being somewhat easier than ten yearsish ago is still a better place to
 be than the cryptographic lockdown.

 I disagree and once again it is not a lockdown as people who care
 enough can disable it, while having it enabled by default makes things
 easier for a large set of (potential) users.

You can disable the lockdown on iOS devices too—and the lawfulness of
this activity is well established in the US.
I understand that when the Copyright Office hit its periodic review
for that particular DMCA exemption Apple didn't even fight it this

It is still a lockdown even if there is some complicated procedure to
disable it—you can't argue this both ways. Either it's an
inconsequential restriction because it's so easy to disable, or it's a
practical problem for people installing the OS.

And what happens when OEMs leave out the option, which isn't even
required by the UEFI spec itself, and Microsoft fails to enforce that
particular requirement?  Not our fault?

 And if we have the choice between make it easier to modify every part
 of the OS vs. make it easier to instal the OS in the first place
 ... no one thinking rationally would opt for the former.

If it were so simple we'd never have free software at all,  because it
was always easier to continue using whatever commercial offering came
bundled with your system.

In this case it's make it easier to install vs. preserve an
ecosystem of cooperating publishers, keep software freedom as a
top-line priority, keep it easy to modify every part, and don't put
Red Hat in the business of defending semi-tivoization against license
enforcement by free software authors.

 Besides installation and modification aside it does provide another
 additional value ... which is added security which is a welcome
 addition in some environments.

There is no additional security provided by the feature as so far
described—only security theater.   So I can't modify the kernel or
bootloader, great—but the kernel wouldn't have let me do that in the
first place unless it had an exploit. So I just put my rootkit inside
systemd so that it executes the kernel exploit right after reboot, and
the exploited kernel now silently keeps updates from being applied.
This has hardly made any attacks more difficult at all.  You don't get
security benefits from this without a much more elaborate and fragile
system, or without mandating the signing of a much larger portion of
the software stack so that updates can run before any unsigned code
(and even then only after the horse has left the barn: the attacker
has stolen your data and wiped the system before reboot).

If you want to improve the security of Fedora, there are a great many
things that can be done which don't have sticky compromises and which
would provide greater actual security.  Moreover, I can find no
feature requests for this functionality. (Instead the internet is
flooded by people asking how to turn off the security facilities
Fedora already has, people on the IRC channel reflexively tell people
to disable SELinux even when doing so isn't required, etc.)
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 5:57 PM, Matthew Garrett wrote:
 You're fine with one level of injustice. I'm fine with another level of
 injustice. Both compromise the freedoms that Fedora currently gives you.

I'm not fine with it. It's an unfortunate situation too. But producing
a single special case trivial display program for users who couldn't
run anything which was truly free at all is hardly comparable to
cryptographically locking down the core of an OS— millions of lines of
code written by other people, and missing an opportunity to help users
regain their complete freedom at a time when they are most ready and
willing to accept a little inconvenience.

You've made the argument that we didn't choose the lockdown the
systems— Microsoft and the OEMs have.  Fine.  But it is we who will be
choosing to restrict Fedora in that environment rather than only a
trivial help-text shim.

I gave extensive argument on several aspect of the balance which I
believe fall in favor not adopting cryptographic lockdown in Fedora.
I'm not opposing cryptographically locking the kernel on a simple
blind principle of software freedom, and so I do not reject the
alternative of a help screen for equally weak reasons.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 6:09 PM, Gregory Maxwell wrote:
 On Sat, Jun 2, 2012 at 5:57 PM, Matthew Garrett wrote:
 You're fine with one level of injustice. I'm fine with another level of
 injustice. Both compromise the freedoms that Fedora currently gives you.

 I'm not fine with it. It's an unfortunate situation too. But producing
 a single special case trivial display program for users who couldn't
 run anything which was truly free at all is hardly comparable to
 cryptographically locking down the core of an OS— millions of lines of
 code written by other people, and missing an opportunity to help users

Apologies for the double response— but it occurs to me that this may
not be clear:

My initial take— and still my preference— is to not participate at
all: Any participation legitimizes this imposition, regardless of how
I feel about the software freedom of a help-display ship.

But people have provided excellent arguments that the silent failure
would be especially confusing and disruptive to users.  I agree with
these concerns, so I offered the idea of a help shim which would
completely address those specific problems while still preserving
99.% of user software freedom and while still being pretty
similar to complete non-participation.

I think it is poor form hold an effort to compromise and find
something that will be acceptable to people who are primarily
concerned with usability against me, or to suggest that I can't argue
that software freedom is important because I'm unwilling to stoop to
whatever fringe ethics you'd like me to uphold.
devel mailing list

Re: *countable infinities only

2012-06-02 Thread Gregory Maxwell
On Sat, Jun 2, 2012 at 6:23 PM, drago01 wrote:
 It can be argued both ways. Modifying software requires more skills
 and knowlegde anyway so it is more acceptable to accept that group of
 people to fiddle with the firmware then everyone including people that
 don't even know what a firmware is. Come on lets not discuss the
 obvious ..

My personal ability to disable the cryptographic lockdown— or to
choose hardware where isn't in question— it's the ability of people I
redistribute the software to that is relevant.

If it were not then I could simply answer your desire to ship signed
binaries with Just disable that option on your computer, tada, no
problems. If thats not a viable an option for Fedora as whole, it's
not an option to someone who is executing the rights Fedora is
required to pass on either.  I don't personally think there is any
ambiguity in this regard the social contract created via copyleft
licenses, if people do then perhaps it's time to strike a new one.

[No disrespect intended, but I'm not point by pointing the rest
because I think the educated reader could easily enough anticipate my
responses from the past thread, we're becoming circular again]
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno wrote:
 So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as 
 tmpfs without causing memory shortfalls
 for everything else they do.
 That's crazy.

Thats not true (and I've used tmpfs for tmp for years, so I'm speaking
from experience)— tmpfs is backed by swap on demand. Just add the
space that you would have used for /tmp to your swap.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 11:27 AM, Gerry Reno wrote:
 Wait a minute.  Back in this thread it says that half of RAM is allocated to 
 the tmpfs for /tmp.
 Plus the purported benefit from this is causing less write cycles on SSD.  
 (See Wiki page)
 That may have been a benefit a few years ago but newer SSD's will gain almost 
 nothing from this because of the enormous
 number of write cycles they handle.

You're not understanding the word allocate in the same way it
actually behaves.  It does not reserve memory. The default maximum
size (think of it as a quota) of a tmpfs mount is half whatever amount
of actual ram you have. You can expand or shrink a tmpfs mount using
the size= mount option.

Memory is not actually used until things are stored there, and if the
result is memory pressure the kernel will intelligently page out the
least used pages. (e.g. tmp files that haven't been accessed in a long
time, or inactive application memory instead of an actively accessed
file on tmp), per the normal vm policy.

Because that disk activity only happens when the kernel decides that
it wants the memory for something else it doesn't happen at all in a
great many cases especially for short lived files.

 This feature may have some benefits but I think they are infinitesimally 

The feature may be adopted/promoted on the basis of SSD writecycle
preservation, but tmpfs also offers considerable performance
improvements for workloads that create/remove files in /tmp at high
speed— which is the reason that many people have been using tmpfs for
/tmp on many systems for much longer than SSDs have existed.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald wrote:
 well designed machines do NOT swap and have not alligend
 swap at all - in the case of virtualization you MUST NOT
 enforce swapping if you really like perofrmance

I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)

The dogmatic 'swap is bad for performance' is justified only because
writing/reading a slow disk is bad for performance.

Tmpfs helps your system avoid disk i/o by giving your system more
flexibility in how it manages all of the available temporary space.

It's something that people who are very concerned with swap impact on
performance should appreciate greatly.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 12:27 PM, DJ Delorie wrote:
 This conclusion is NOT TRUE for me.  I've checked it.  /tmp on ext3 on
 my system does NOT incur any disk I/O until long after the process
 using it has finished, if at all, as long as the files are small and

Glad to see you've taken the all caps advice.

I'm not sure what you're measuring though, because the metadata
absolutely does get written write away for me. For a more dramatic
example touch a file then hit the power button a few seconds later.

 And if they're neither small nor transient, RAM is the wrong place for
 them anyway.

If they really aren't transient then /tmp is the wrong place for them.
But regardless, if ram isn't the IO optimal place for them then they
won't remain in ram.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 2:28 PM, DJ Delorie wrote:
 If they really aren't transient then /tmp is the wrong place for them.
 I will categorically disagree with any argument of the the user
 shouldn't be doing that type.  Software exists to serve the user, not
 the other way around.

Your quoting removed the fact that I was responding a statement that
ram was the wrong place.  I was simply extending the comment. If
you're willing to say that ram is the wrong place for something then
there is nothing user hostile to say tmp is too.

Tmp already gets ruthlessly script deleted. It's really not a good
place to keep things you're planning on keeping for a long time, tmpfs
or no.
devel mailing list

Re: Action required: Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 1:02 PM, Simo Sorce wrote:
 On my 'normal' systems once the desktop is fully started with Firfox,
 Gnome, Evolution and all the crap, I already am using more than half the
 RAM available, so tmpfs in RAM means I hit swap as soon as something
 decides to write a tmp file as if we didn't have enough I/O issues with
 latest kernels in Fedora, isn't that awesome ? Not!

No. Thats not what it means.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 2:46 PM, DJ Delorie wrote:
 *I* want /tmp on disk.  I still don't want someone else telling me I
 have to do it that way.

You can still put tmp on a disk if you're the kind of advanced users
who knows better enough to override the defaults.

But there does have to be a default.   Fedora makes _many_ defaults
which I find intolerable, coping with that and the breakage that comes
from making my fedora install less standard is part of the costs of
outsourcing my system administration to the fedora community— a cost
that is usually well worth the benefit.

Many of the people responding to this have show a substantial
misunderstanding of how it would work— e.g. the thought it would take
up half their ram. Adding a prompt is not costless by any means, and I
don't think it actually would achieve the goal of aligning the users
needs with the system's behavior. It also doesn't scale to the
millions of other decisions Fedora and its packages make on the user's

I think it's reasonable to demand that fedora continues to support a
on-disk /tmp.  But ... yea. You can't escape having defaults.

(My own complaints in Fedora e.g. about gnome3, for example— have been
about how crappy the fedora experience is if you disable the gnome
stuff, how many things break in mysterious ways, not that Fedora has a
default I don't like)
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 2:50 PM, Michael Cronenworth wrote:
 Not a single person who has claimed a performance or semantic win for
 this /tmp move has replied when asked for proof.

I haven't bothered because I have no clue what you'll accept and I
fully accept you to move the goalposts.

For example, I build firefox in /tmp which is on tmpfs for me because
on mostly finished trees the make is about 40% faster than with it on
the disk. (51 seconds vs 72 seconds.
devel mailing list

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Gregory Maxwell
On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald wrote:
 I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)

 The dogmatic 'swap is bad for performance' is justified only because
 writing/reading a slow disk is bad for performance.

 and how does /tmp in RAm change this?

 it enforces swapping because temporary files are
 held completly in memory and if they are large
 enough and your workload needs active RAm you
 enforce swapping

They are not held 'completely' in memory. The kernel can choose where
to store them based on the current demands on the system.  It can
store them on disk (though more cheaply than other FSes because it
doesn't have to worry about it being recoverable across a reboot) or
in memory.

 if they are on disk under /tmp they are cached only
 as long page-cache or active RAM is not needed for
 the workload and the memory can be released instead
 WRITE it do disk with swapping

This is how tmpfs works too, except without tmpfs some write activity
is required because the metadata updates (and data for sufficiently
long lived tmp files) will be written to disk.   So what the normal
buffer cache does for reading tmpfs lets it also do for writing.

On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald wrote:
 * it is a valid workload that a application creates a 10 GB tempfile
 * ok, you say: use /var/tmp
 * well, i say: my whole rootfs is only 4 GB and 2 Gb are used

If your rootfs wasn't big enough for your tmp workload you would have
had to have had a separate tmp partition. Either continue to use it—
or mount it as swap and set size= to allow you to use it in tmp.

It works great.

On Fri, Jun 1, 2012 at 4:14 PM, Chris Adams wrote:
 I keep seeing sort as the primary example: how often are people sorting
 multi-gigabyte files?

I do this sort of crazy stuff all the time.  But— if I were just a
random user and did that sort of stuff I'd run out of space on root in
the process.  I don't run out of space in tmp because I make my tmp
big enough... just like I'd have to do if I wasn't using tmpfs.  Weird
workload require considerations, the use of tmpfs changing the default
tmp size might  move the weirdness boundary line around some but it
doesn't make a fundamental change in that.

At the same time it'll also be a good opportunity to find and fix
software that is needlessly writing enormous outputs to /tmp (which
could have been problematic for all users, including doing things like
causing data loss when /tmp is on the same volume as /home and filling
it up causes your programs to save zero byte file).
devel mailing list

*countable infinities only

2012-05-31 Thread Gregory Maxwell
From Fedora 18 on, Fedora will no longer include the freedom to for a
user to create a fork or respin which is the technological equal of
the Project's output. Instead, this freedom will be available
exclusively from Microsoft for $99 under unspecified conditions.

I wish this were a joke.
devel mailing list

Re: *countable infinities only

2012-05-31 Thread Gregory Maxwell
On Thu, May 31, 2012 at 9:56 AM, Bryn M. Reeves wrote:
 abundantly clear that there are no restrictions placed on users who do
 not wish to have the secure boot signature checks enforced.

Yes, I read it and spent several hours talking to MJG before he posted
it, in fact.

I thought I'd pay him the respect of sleeping on it and giving someone
in support of this rather secretive move time to post about it and
discuss it, so that people wouldn't be learning about it from my
response.   I also wrote a simple, factual message.  Nothing I said
was distorted or untrue.

This may not be the end of the world, but it's a clear loss of a
freedom that Fedora has had in the past. See below:

On Thu, May 31, 2012 at 10:04 AM, Peter Jones wrote:
 You're wrong.  Users will have the ability to create their own signing
 certificates with openssl and sign their own binaries. Using MS as a signer
 only buys you the convenience of not making everybody who wants to install
 your software enroll your key.  But they will be able to do that if that's
 what you want.

It's perhaps just as troubling that there are people involved in this
non-public decision who apparently have such a limited understanding
of free software that they were unable to understand the point I made
explicitly in my message (and more elliptically in my subject).   How
can I trust that you really had no other alternative, when you can't
even see the loss of freedom associated with this?

One of the Infinite Freedoms Fedora has previously included is the
infinite potential of creating forks— software that _other people_
will load— which are Fedora's technological equals and which
themselves enjoy the same freedom as Fedora.  A change from an
uncountable infinity of options, to a merely countable infinity.

Under this model there will be two classes of distributor: One which
loads easily on systems, and one which requires the additional effort
of disabling secure boot or installing user keys. (And ARM will be
even more interesting...)

You might argue that the cost of installing keys / disabling
secure-boot is sufficiently low— but if if it really were, why bother
with it for Fedora, why legitimize this kind of signed boot-loader
only control by playing along with it.

So perhaps in practice the loss of freedom is small—  but at the same
time people advocating closed software will rightly point out that
very few users can program and fewer still care to actually do so.
None the less,  I do not believe it is FUD or in any way inaccurate
to say that this will mean that Fedora will be losing a freedom it
once had— the freedom to make forks at no cost which are technically
equal to the projects, ones which are just as compatible and easy to
devel mailing list

*countable infinities only

2012-05-31 Thread Gregory Maxwell
[I'm sorry for getting repetitive here, but I'm responding to several
people concurrently in order to minimize volume]

On Thu, May 31, 2012 at 10:32 AM, Bryn M. Reeves wrote:
 That discussion is happening right now. You're welcome to join in.

That wasn't my understanding, my understanding is that this is a done
deal and not up for discussion. I'm happy to learn otherwise.

 It's rather disingenuous to suggest that this is a situation of
 Fedora's making. This is coming whether we or other distributions like
 it or not as a consequence of the Windows 8 logo program.

I did not say that this situation was fedora's making, I know — for example—
That MJG cares deeply about software freedom and that he understands
the loss of freedom here.  I know that everyone involved in this feels that
it is being exposed from outside and that there is no other viable choice.
(And I grant that there is at least a choice of bad compromises being
enforced from outside).

This does not change the fact that a freedom of fedora is being lost.

And Fedora does have a choice here.

 If you think you have a better scheme then please describe it.

I know that the people who have been working on this for months and in
direct negation with Microsoft have already explored more options than
I can hope to guess at.  I won't be able to outdo a bunch of really
smart people working, with the cooperation of lawyers, for months in
an email here (and I already attempted this in private with MJG, and
failed as expected).

I offer instead that Fedora should not participate and leave it so
that Fedora and forks will both have equal inconvenience on this
hardware. This will preserve the freedom I'm speaking of losing here,
and it will keep Redhat and the Fedora community laser focused on
minimizing this inconvenience.

[and I didn't spell this out before simply because it's an obvious
option that you don't need my help to find]

The plan presented here will instead potentially leave RedHat and the
Fedora community in the odd position of defending TC lockdown as
compatible with the GPLv2 installation instructions, v3 anti-TC, and
future licenses which may be _specifically_ targeted to address the
loss of freedom created here — I'm not trying to argue that the
licensing here myself,  only pointing out that the fact that you'll
now be in the business of arguing against prohibitions in free
software licenses is a very clear sign that something is wrong, and a
very bad investment in resources.

The overall situation here is not Fedora's making— not something you
would choose to have.  But there absolutely is a choice available
here.  Fedora can choose to continue to participate in the ecosystem
as an equal— without access to special signing keys which they can't
give to their users would may wish to make forks—, or Fedora can
choose to make the install easier on this hardware.

And it's not to say that I'm 100% doom and gloom about this, the
increase in friction for loading binary only drivers will be a very
positive upside.

 Perhaps to give the users who want to have Fedora cohabit with another
 OS that uses trusted boot the freedom do do so without turning it off?

And again—   Forks and Respins of Fedora lose the ability to provide
parity in this regard.

I apologize that I'm presenting you with an impossible argument: You
argue that it's important to do this, I argue that the loss of freedom
is great— you argue that the hurdles for forks/respins are small,  I
argue that you should not do this.   But it isn't me who created this
dissonance.   It's the people arguing that this is not a clear loss of
a prior freedom in Fedora.

Once you accept that this option is a loss of freedom then the
argument is no longer cyclic and we can have a meaningful discussion
about if the loss of freedom is better or worse than the loss of

 Starting a new thread that deliberately omits important aspects (such
 as the user's ability to toss out and replace vendor keys or disable
 the whole mess) is pretty close to my definition of fear, uncertainty
 and doubt.

That isn't a relevant aspect for someone who would want to fork the
software for other people to use. The relevant part is that if you
fork fedora you will either have to pay $99 (and pass whatever
certification Microsoft imposes) or you will be harder to install.  If
you think that my focus on this point to the exclusion of all the ways
that this doesn't suck— ways which would likely be unlawful— is going
to confuse people, then perhaps you should communicate about this
better so that I'm unable to confuse people.

On Thu, May 31, 2012 at 10:34 AM, Peter Jones wrote:
 You keep using technological equals when you clearly mean market equals.
 The technology is all there. The market is what's more difficult to gain
 access to. I'm not happy about that at all, but it's still a worthwhile

Access to cryptographic signing keys is a technological 

Re: *countable infinities only

2012-05-31 Thread Gregory Maxwell
On Thu, May 31, 2012 at 12:11 PM, Gerry Reno wrote:
 This is a monopolistic attack disguised as a security effort.
 The highly restrictive technological approach that has been taken needs to be 
 challenged in the courts.
 I'd rather see Microsoft users have to attach a dongle to their system to get 
 the security that they need.

My understanding is that some of the relevant legal minds believe that
Microsoft's you can disable it concession forecloses the possibility
of a successful legal attack on this— the law may care about the
anti-competativeness of this stuff, but not so much as to care about a
$99 signing key or some minor install time hurdle. (and the fact that
fedora is willing to plan this probably justifies this position).

It was arguably a strategic error to blow the whistle in advance and
give Microsoft time to compromise. Their first attempt was much more
likely to have created a civil cause of action as well as to have run
afoul on antitrust grounds.   But I can hardly blame anyone for
trying.  Hindsight 20/20 and all that.

On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač wrote:
 That is just untrue.  SecureBoot can be used to make sure you only run
 the software you intended to run, which is impossible without
 SecureBoot (e.g. this cannot be done with a TPM).  The idea is solid,

I don't think this is fair.

SecureBoot doesn't protect you from someone with access to the
hardware (they can disable secureboot).  And if your kernel is secure
than userspace malware can also not change your boot environment.
If your kernel is _not_ secure then the malware will just modify the
first piece of unsigned userspace code (e.g. systemd) so that it
executes the kernel exploit at startup before updates have a chance to
run, and the kernel rootkit will prevent the updates.

So unless you take the route of signing everything (with the according
loss of software freedom, and a lot of runtime overhead) this actually
doesn't buy you a lot.

Microsoft's competitive advantage is that they lose little by locking
down everything and will potentially get more security as a result.
Fedora's pas competitive advantage was that it provided its users with
the freedom to change the whole system with low friction— something
MSFT's business model can't allow.   By playing along we legitimize
their advantages and weaken our own.  And in practice, since we won't
accept a full lock down (nor, hopefully would the licenses permit it),
Fedora will mostly not enjoy the security benefit.

On Thu, May 31, 2012 at 12:20 PM, Basil Mohamed Gohar wrote:
 Ah, yes, but then you also won't be able to run Fedora, under the
 currently proposed solution.  Oops!  See how slick the slope is?

They could if they replace the key while removing the MSFT one, or
disable secure boot at the same time.
devel mailing list

Re: *countable infinities only

2012-05-31 Thread Gregory Maxwell
On Thu, May 31, 2012 at 1:07 PM, Gerry Reno wrote:
 Could be any of a thousand ways to implement this.
 Maybe it checks the BIOS to determine whether some SecureBoot flag is set.

While it pains me to argue with someone on my side— you're incorrect.
The compromised system would just intercept and emulate or patch out that test.

I think I gave a reasonable outline as to why this is pointless— that
the unsigned userspace will just keep reexploiting the kernel after
boot and before updates be installed.
devel mailing list

Re: *countable infinities only

2012-05-31 Thread Gregory Maxwell
On Thu, May 31, 2012 at 12:47 PM, Bill Nottingham wrote:
 I'm not sure how you meant this, but I'm having a hard time reading this in
 a way that's not:

 - directly contradictory
 - intentional raising of FUD then stepping back
 - insinuating some Shadowy Cabal Of Others behind this decision

 Hopefully you meant something else?

I wasn't responding to MJG, I was responding to Peter— who said I was
wrong in the message where I was stating that a freedom is being lost,
and has subsequently spoken more clearly on the position— and Byrn.
It seemed to me that they were arguing that the freedom of fedora
wasn't being compromised here.  My understanding has been refined by
further discussion, though I'm still not completely sure if all people
actually take the loss of freedom seriously, or if they do but just
can't accept the idea that the alternative is actually an option.

As far as the Shadowy Cabal— Come on, you know thats how real work is
done anyways.  This absolutely has been discussed and decided on in
private, all for various reason which are believed to be good by the
participants.  And they may well be right about that, and public
backlash may still revert it. (and may ultimately be mistaken for
doing so).

I wasn't trying to complain about shadowy cabals, I was just defending
myself against the crap argument that it wasn't final when I know that
the claims that it's not final do not accurately reflect the views
held privately by at least some of the involved parties. I will gladly
eat a hat should fedora not go down this path.

 In any case, I'm not really understanding the cabal implications here.
 Matthew and Peter did this work for Fedora as part of their maintainer
 responsibilities for the x86 boot portion of Fedora, much as the KDE

Because maintaining the boot portion of the system shouldn't
automatically create a position to make fundamental decisions like
this.  The authors of Fedora packages also don't normally spend large
amounts of time in consultation with Redhat legal, Microsoft,
consortiums, etc.

This is not a normal situation, come on now.

 Yes, we all understand what freedoms are being lost here. Fedora has made
 compromises in the past, not limited to:
 - No third party can have their software trusted to be installed on Fedora
  by default - we don't hand out RPM signing keys.
 - Hey, look at that binary firmware over there.

I'm very glad that you're being up front about this here— Can I expect
you to see other messages from you in this thread and elsewhere
correcting people who argue that a freedom isn't being lost here?

And yes— Fedora has made compromises and there are many compromises it
hasn't made— including many around hardware compatibility.  I think
this is more of a compromise than some ones it hasn't made.  I accept
that this is something that can be debated.  But not if that debate
keeps getting undermined by people trying to distract from the real
loss of freedom by pointing out that individual users can currently
disable this stuff by efforts which are apparently too heroic for
Fedora to consider them tolerable by the majority of its users.

How about a statement that is just this upfront about this from the
very first words such as,  Fedora is taking away some freedom's from
its users— an action which is against the general guidance of the
project's values. We were not forced to take away these freedoms but
the leadership unanimously believes the only alternatives are worse
for everyone. We regret this compromise vow to continue to fight to
minimize its harms but we think this is the best option available

If Fedora is going to compromise there are ways of doing it which
almost everyone can be proud of, but they all start with being
brutally honest.   I don't feel like many of the responses here— which
belabor the ability of the user to jailbreak, if you will, their
secureboot can be characterized as brutally honest, because they deny
that a freedom is being lost here.

Though— as far as I can tell, the ability to disable is entirely not
up to Fedora. If Dell removes the ability to disable— something far
more palatable if it doesn't lock out the major commercially sponsored
Linux distributions—  what recourse do you have and what would
motivate you to take it?  It's something of a slippery-slope concern
but certainly ARM provides strong evidence that this ability will
vanish as soon as excuse (like security compromises) or opportunity
(like the adoption of secure boot by major GNU/Linux vendors removing
antitrust concerns), makes it possible).  As far as I can tell this is
not a law of nature, and is only so right now because you managed to
scare MSFT into thinking the harder lockdown would be legally risky.
(Congrats on that, this effort isn't unappropriated)

But... If Fedora can't prevent this future UEFI systems from not
allowing users to disable secureboot or add keys you ought to be
upfront about that too.

 Furthermore, there's 

Re: *countable infinities only

2012-05-31 Thread Gregory Maxwell
On Thu, May 31, 2012 at 4:19 PM, Gerry Reno wrote:
 And I'd rather see a User-Controlled implementation rather than a 
 Monopoly-Controlled implementation.

SecureBoot is (currently, on x86 but not arm) _also_ user-controlled.
The monopoly controlled is just the default.
devel mailing list

Re: pidgin-otr security update pushed - please test and give karma

2012-05-16 Thread Gregory Maxwell
On Wed, May 16, 2012 at 10:16 AM, Paul Wouters wrote:
 Please test and give karma so this security release won't get stuck for
 too long.

To add Karma, after testing log into that page and add a comment
devel mailing list

Re: x32 abi support?

2012-05-16 Thread Gregory Maxwell
On Wed, May 16, 2012 at 10:41 AM, Jakub Jelinek wrote:
 And, for various programs you usually don't need 64-bit address space,
 but in the case where you have say bigger input you are simply out of luck
 if you are limited to 32-bit address space.  Say with compilers/linkers,
 you can usually compile smaller stuff just fine with 32-bit compiler, but
 if you have some larger source code, x32 won't do it.  Similarly
 various other programs that don't have constant memory requirements, but
 linear (or worse) with the size of the input.

It's for this reason (and the multilib memory bloat) that I was really
disappointed to see x32 created.

32bit of an addressable space is a real limitation on modern machines—
and completely reasonable software which is linear in input size is
simply less useful on 32 bit machines.

If it ever comes up that Fedora wants to further limit the usability
of the i686 with older machines (e.g. by adding a SSE2 requirement),
then perhaps it would be instead better to replace i686 with x32...
but otherwise I think it would be really unfortunate to end up
subjecting fedora users to the 32bit vm limits who otherwise might not
devel mailing list

Re: urandom vs haveged

2012-03-26 Thread Gregory Maxwell
On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy wrote:
 So then the question is, if urandom is what's recommended, are faster 
 substitutes just as good? If they are just as good, then why aren't they the 
 first recommendation? And if this step is superfluous, then I'd suggest 
 documentation be changed to eliminate the suggestion altogether.

Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the
key and one of the secure block modes (e.g. aes-lrw or aes-essiv).
Then I fill the dmcrypt device with /dev/zero.  This goes fairly fast,
filling the device with securely encrypted zeros.

Then I drop the volume and set up luks normally.

From a security perspective an attack which allowed the attacker to
distinguish the randomly encrypted /dev/zero from your other data
would be a fairly bad vulnerability generally against the encrypted
volume... much worse than the information leak wrt used blocks.
devel mailing list

Re: Apple will use LLVM

2012-02-16 Thread Gregory Maxwell
On Thu, Feb 16, 2012 at 10:25 AM, Vladimir Makarov wrote:
 GCC has a big community of very dedicated people.  LLVM has no such
 community.  So IMHO GCC will be more high quality compiler than LLVM until
 LLVM gets such community.

That can't be expected to continue now that there are many employers
hiring people and forbidding them from working on GCC, even in their
own time, while permitting them to work on LLVM.

I'm not just spreading sour news for the sake of it, here is an
example of where I ran into this impeding a GCC crash bug:

(Though it will be quite ironic when LLVM becomes unusable to everyone
because the we don't give up our patent rights for this when we
contribute to it turns it into a thicket)
devel mailing list

Re: A software center for Fedora

2011-11-27 Thread Gregory Maxwell
On Sun, Nov 27, 2011 at 4:14 PM, Bernd Stramm wrote:
 Removing the screenshots, icons, popularity vote results etc etc
 post-install is not a good solution. These things should be available
 when someone wants to look at them, not installed by default.

 The mechanisms to look at them should be there unless removed, but not
 the advertising for several thousand packages.

Since the install can't happen unless you're online— why not load
these screenshots over the network on demand?

I was just making fun of an ubuntu desktop install the other day: No
NFS client but 100 mbytes of icons.

None of these decisions exist in a vacuum— if fedora is to include
many megabytes of screenshots in the default install then thats a
great many applications which can't be installed.

For many simple programs a good high resolution screenshot of the
program will be similar in size to the program.
devel mailing list

Re: A software center for Fedora

2011-11-26 Thread Gregory Maxwell
On Fri, Nov 25, 2011 at 6:28 PM, Laurin wrote:
 I totally agree with you, a software center would be a really nice idea,
 also for more experienced user because they can browse easily through the
 available software and may find something interesting.

I am really confused by this thread.

Here is what my F14 laptop has:

It can be configured to only show end-user graphical applications and
to hide subpackages, via the filters dialog though this isn't the
default (and I don't think it should be— unless a way of turning off
the filters is made more discoverable).

This thread was mentioned on IRC and I asked about it because I
couldn't understand it.

I wasn't able to get an explanation I found acceptable...

One thing that was suggested is that a software center would only
show graphical end user apps, and would hide libraries and
sub-packages. But, as I point out, the software in Fedora can already
do this.

It was also suggested that a software center would highlight or
promote typical tools that an average person would need—  I'm skip
the rant about Fedora's myopic definitions of an average person, and
focus on typical: If there is a application which most average users
will need— why isn't it in the default desktop install?

Can someone help me understand whats being asked for here? I can only
guess that I'm not the only person confused by this thread.
devel mailing list

Re: Package segfaults when built with -O2 but not with -O0

2011-11-18 Thread Gregory Maxwell
On Fri, Nov 18, 2011 at 6:31 AM, Paul Howarth wrote:
 2. How to determine what the actual problem is, e.g. a problem with the
 way the code is written leading to unsafe optimizations, or a gcc bug?

[Obviously Andrew's look at warnings advice is good but also…]

See if you can reproduce it when compiled with -O2 -fno-strict-aliasing
if not, then the package violates C rules for pointer aliasing and
-Wstrict-aliasing=n can help you find the bug.

Otherwise, reproduce the crash while running in valgrind and it's pretty
likely that you'll see the cause there. (e.g. some use-uninitilized which
turns out to be harmless in O0)

Between these two that covers a pretty significant portion of bugs that
vanish at O0.
devel mailing list

Re: Package segfaults when built with -O2 but not with -O0

2011-11-18 Thread Gregory Maxwell
On Fri, Nov 18, 2011 at 11:27 PM, Ralf Corsepius wrote:
 [1] -Wstrict-aliasing is one of these cases.
 The spots such warnings point to, often are broken, but not always,
 because GCC has difficulties in identifying these.

This use to be more true, but there are multiple levels of -Wstrict-aliasing and
I would be _highly_ surprised if the default gave a false alarm. I think you
can reliably say that if you get a warning at the default level then you do
have a language standards conformance problem, and that it actually changes
the generated code... but maybe you don't actually crash on any
particular system.

I don't think 'the code is objectively wrong in a meaningful way' is a
false alarm.

I've seen code that miscompiled and crashed due to violating the aliasing rules
but only threw a warning at higher levels. It's arguably too
conservative already.

If GCC is sure something is wrong, it is supposed to raise errors.

This isn't true. E.g. you can write code which reads and uses
uninitialized memory
where the compiler is _absolutely sure_ of it. You still just get a warning. The
compiler would be compatible with the spec if it replaced this program with
system(rm -rf /), but you only get a warning.

I quote the manual: Errors report problems that make it impossible to
compile your program.

(Though I agree with your view wrt the unfortunateness of
style-warnings (omg you used a
^ without fifty parentheses) being hard to separate from ones where
the compiler knows
that your code is broken.)
devel mailing list

Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.

2011-11-07 Thread Gregory Maxwell
On Mon, Nov 7, 2011 at 8:48 PM, Lennart Poettering wrote:
 If run on the main namespace all they see is that the files are in some
 randomized subdir of /tmp, instead of /tmp itself.

Is the randomization required? If they were named after the
user/service that created
them (perhaps with some randomization too e.g.
/tmp/mount.fooservice.$random would be
much more discoverable and maintainable then /tmp/$random.  Systemctl
show is good
and needed for automation, but my brain stores more sysadmin trivial
than I like already.
devel mailing list

Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.

2011-11-07 Thread Gregory Maxwell
On Mon, Nov 7, 2011 at 10:00 PM, Chris Adams wrote:
 Well, if they're subdirectories of /tmp, you'd have to deal with all the
 usual /tmp attacks of known targets.

Hmph? They wouldn't be accessible to anything except root I assume.

Because they're long lived the random names shouldn't provide much
protection— and certainly not much more than partially random names
would provide. Or am I missing something?
devel mailing list

Re: GNOME 3 - font point sizes now scaled?

2011-09-30 Thread Gregory Maxwell
On Fri, Sep 30, 2011 at 8:53 PM, Kevin Kofler wrote:
 Daniel Drake wrote:
 Summary: GNOME hardcodes DPI to 96 regardless of X configuration.

 This is very broken.

Gnome: Reliving Window's horrible past, one emulated bug at a time.

At least we can be thankful that unlike windows, gnome doesn't have
the market force required for their flaws to retard the availability
of displays with reasonable pixel densities.

devel mailing list

Re: [HEADS UP] remove ddate(1) command from rawhide

2011-08-29 Thread Gregory Maxwell
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram wrote:
 Otherwise,  make
 ddate a sub package and don't install it by default.   Solved?

As an upstream the willingness of distributions to strip out commands
which I wanted to provide and don't offer a build option to disable
via sub-packaging will simply encourage me to pack more functionality
into single binaries that the distributions won't strip.

So I think Fedora shouldn't be more willing to strip ddate than it
would be willing to patch out ddate functionality if it were embedded
in 'hwclock'.

There is a reasonable argument that util-linux ought to go on a diet:
Right now it appears to take up 6424k on disk.

(Though, most of that is localizations— and several of the various
NEWS/readme files it includes are bigger than ddate, as is its copy of
the GPL. This silly thread has probably taken up more disk space than
ddate, or it soon will)
devel mailing list

Re: Trusted Boot in Fedora

2011-06-24 Thread Gregory Maxwell
On Fri, Jun 24, 2011 at 4:07 AM, Rahul Sundaram wrote:
 If you have *specific* concerns,  let's hear those.  You seem to just
 quoting parts of a public wiki page anyone can read.  I don't see the
 point of that

If trusted boot in fedora is widely deployed, then $random_things may
demand I use a particular fedora kernel in order to access them.  Both
handcapping my personal freedom to tinker with my own computer by
imposing new costs on it, and hampering the Fedora project by creating
additional friction against upgrades.
(Sorry, I can't upgrade to the new kernel to test that, because then
I won't be able to watch netflicks!)

In cases where remote attestation is especially important for
legitimate purposes then it would be completely acceptable to require
the user to enable it. Making it work by default will encourage the
use of the functionality in places where it is not important, because
the community of tinkerers and innovators is simply small enough to

Is that the world we want to live in?  Why should our project
contribute to that world's creation?

I think the wide (e.g. by default) deployment of remote attestation
undermines the Fedora foundational value of freedom and will inhibit
the innovation which is central to the project's mission. Accordingly,
support for remote attestation in the default install should be
explicitly and categorically rejected with the same vigor, and many of
the same reasons, that the project rejects proprietary software which
it could lawfully distribute.
devel mailing list

Re: Trusted Boot in Fedora

2011-06-24 Thread Gregory Maxwell
2011/6/24 Tomas Mraz
 On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote:
 On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell wrote:
  If trusted boot in fedora is widely deployed, then $random_things may
  demand I use a particular fedora kernel in order to access them.

 I can't see how it would make any difference whether Fedora supports
 the feature or not - after all, any vendor can add patch Fedora to add
 TPM support and then $random_things may demand you use a particular
 vendor-modified Fedora in order to access them - or a particular
 non-Fedora operating system, just as well.

The userbase of Fedora as a whole is substantially larger than the
userbase of fedora users who run non-default kernels. The small
benefit of mandatory remote attestation could be far more easily
outweighed by the loss of the whole Fedora userbase than it could be
outweighed by the loss of the tiny subset of the Fedora users who are
actively practicing the freedom's theoretically provided by Fedora
(and wouldn't simply stop if the freedom was made costly by a

[I can make clear examples of cases where large relevant internet
resources chose to exclude userbases larger than
Fedora-users-with-modified kernels for just slight convenience, but
took inconvenience to support ones comparable in size to Fedora, but
I'm trying to stay scrupulously on-topic]

 Yes, I completely agree. What Gregory tries to emphasis here - as I
 understand it, of course he might have a different intention - is purely
 politics and I do not think, that Fedora should involve in political
 decisions in one way or another.

 If the feature conforms to Fedora legal requirements and the developers
 of the affected packages are OK with integrating necessary patches, it
 should be allowed.

I'm puzzled by this response.  Would you also support Fedora packaging
and distributing proprietary binary only applications offered under a
license which legally allows Fedora to do so, but which disallowed the
end user the freedom to modify and understand the software?  How is
this also not equally political?

The Fedora project has a specific mission with numerous points around
software innovation which is grounded on a set of foundational
principles with include the users freedom. A likely end result of the
default inclusion of this functionality will degrade these goals. (And
if you do not think that remote attestation will ever be used to
regulate access as has been proposed here, what do you intend to use
it for?)

Personally, I think it is of greater practical concern to me that I
retain the ability to have equal functionality via my system no matter
if I run a non-standard kernel or not, more practically important that
if fedora ships a few binary-only applications here and there.

More technically, can the software be modified to refuse to disclose
the signature which links the chip specific TPM key to any third party
TPM trust root?  If this were not disclosed the functionality could
not be used for third party attestation, but e.g. users could still
use it to make sure a root kit had not been installed on one of their
systems before remotely providing keys because they could simply
remember their hardware's keys rather than validating them against the
manufacturers keys, but a third party that wanted to deny access to
non-standard fedora configurations would have no way to know if the
attestation were authentic. Users could still boot into a special
modified kernel to obtain that linkage, but I believe the simple
roadblock of not making it available by default would address my
devel mailing list

Re: Delayed encrypted partition mount

2011-03-21 Thread Gregory Maxwell
On Mon, Mar 21, 2011 at 10:22 AM, Gilboa Davara wrote:
 Hello all,

 I routinely encrypt all important partitions on my laptops /
 workstations / servers using LUKS both at home and at work.
 However, due to the above, I can no longer remotely reboot the machines
 (at least the ones that doesn't have a serial console attached) as I'm
 required to baby-sit the machine until the password prompt appears.

 My question is simple: Given the fact that I rarely encrypt the root,
 can I somehow delay the encrypted partition mount to right-before-gdm,
 so all the essential services (samba, nfs, cups) - especially network
 and sshd, will be up, so I can remotely type the password required to
 mount the encrypted partitions?

 I could delete the entries from /etc/cryptab, create a service that will
 mount the partitions late in the boot process, but AFAIK, this will not
 display the graphical password prompt making it less than ideal...

You can use pam_mount (available as part of fedora) to make the system
mount encrypted file systems at login using the same password you use
for login.

I've used this for a number of years, and it's very nice. I recommend it.

The only problem I've had with it is that the syntax has changed
between fedora versions and caused me to have to waste a little time
relearning it... well, that and it adds a few steps to setting up
a new system.
devel mailing list

Re: New celt build broke jack-audio-connection-kit...

2011-02-19 Thread Gregory Maxwell
On Sat, Feb 19, 2011 at 6:56 PM, Michael S wrote:
 On 20 February 2011 00:40, Orcan Ogetbil wrote:
 On Sat, Feb 19, 2011 at 6:29 PM, Michael S wrote:
 On 17 February 2011 01:02, Jeffrey Ollie wrote:
 I was just trying to build the latest Asterisk, which uses
 jack-audio-connection-kit, but it looks like the most recent build of
 celt from this afternoon broke the build:

 DEBUG is needed by

 SONAME bump and API change in the new CELT.

 I've jumped in to fix this in Rawhide as it had broken the koji
 buildroot creation for more packages. Couldn't find any announcement
 or thread about this upgrade, so I don't know if anyone else was
 working on it.

 I was working on it. Next time, please send an email to the actual
 package maintainers beforehand so we don't duplicate the work.

 The %changelog mentions two rebuild attempts of JACK (not by you) four
 days ago and no activity later than. I didn't expect anybody to work
 on a fix for several days, so after having waited three days for a
 fixed build to appear, I discovered this thread, and the risk of
 duplicating a little bit of work was very small.

Did any of you actually try it?

From looking at the changes to jack and how libcelt is built, this
couldn't possibly work.
devel mailing list

Re: New celt build broke jack-audio-connection-kit...

2011-02-19 Thread Gregory Maxwell
On Sat, Feb 19, 2011 at 9:13 PM, Orcan Ogetbil wrote:
 I didn't try Michael's fix myself since I don't have a rawhide box
 with real audio hardware.

 But looking at the celt code, specifically to the implementations of
 celt_decoder_create() and celt_decoder_create_custom() , I don't think
 Michael did it wrong.

 Am I missing something? Why shouldn't it work?

Two reasons, the libcelt package is not compiled with
--enable-custom-modes, so it will not support anything but the frame
sizes of 120,240,480, and 960 at 48kHz and no other.  The netjack
functionality matches the CELT mode to the jack period which must be a
power of two (64,128,256,512,1024) as using another size would add
additional delay.  As the 0.11 package is compiled it can not be used
for netjack.

It was perhaps foolish of us to not enable custom modes in the default
build— it certainly isn't how a Linux system distributor should be
shipping it. I expect that we'll fix that in the next release of the

The second issue is that the celt-0.8 patch included in the SRPM is
incorrect— for some unimaginable reason it provides NULL to the
frame-size parameter, at first I assumed that this never could have
worked, but then I remembered that the input validation in libcelt was
previously broken. The broken code was managing to pick the largest
frame size supported by the current mode, which happened to coincide
with the frame sizes that the jack was asking for, which was why it
probably did work at one point instead of creating unintelligible
audio and reliably writing outside of the provided buffer.

Finally, jack now needs to call the CELT_SET_INPUT_CLIPPING API on the
encoder to prevent the codec clipping the input levels at 0dBFs.  I
emailed the authors of the netjack functionality when we changed the
clipping behavior because I knew it would impact their use case and
made sure to have an API to get the old behavior back. Though I
haven't heard anything from them.

If someone can get the libcelt package in fedora compiled with
--enable-custom-modes I can provide revised and tested patches for
jack.  I'm clueless about the fedora packaging process— but as one of
the libcelt authors and a netjack user I know this software rather
well and I'm perfectly comfortable hacking on it.
devel mailing list

Re: Local system security

2011-01-05 Thread Gregory Maxwell
On Wed, Jan 5, 2011 at 4:13 PM, Adam Jackson wrote:
 But prevention of DoS on the part of local actors is just not a game you
 can win.  If nothing else, remember that the way Linux implements
 malloc() assumes you have infinite memory, which means you overcommit
 resources, which means failure happens.  You can write code that

# echo 2  /proc/sys/vm/overcommit_memory
# echo 0  /proc/sys/vm/overcommit_ratio


(and good luck with that!)
devel mailing list

Re: memcpy overlap: quickly detect, diagnose, work around

2010-11-29 Thread Gregory Maxwell
On Mon, Nov 29, 2010 at 6:35 PM, John Reiser wrote:
 While the details of inlining are subject
 to change, copying in ascending address order is the order that is
 assumed by all violators of the no-overlap requirement.

All violators? Citation needed.

I'm sure lurking somewhere there are ovelap copies which have no
'assumption' at all— some bad luck with arithmetic makes it ovelap
during some rare alignment of the stars... though cases like that
aren't going to be the ones that get inlined by GCC.
devel mailing list

Re: Fixing the glibc adobe flash incompatibility

2010-11-17 Thread Gregory Maxwell
On Wed, Nov 17, 2010 at 5:11 PM, Genes MailLists wrote:

  Lets also not forget that the motivation for changing memcpy was to
 get some speedup - has anyone seen evidence of any significant benefit
 of that glibc change?

  The BZ ref'd in this thread has linus' (simple) tests which dont
 confirm any benefit of the change compared to his simpler version (which
 does not go backwards).

  So why make a change which only has downside and little to no upside?

The original testing that went with the GLIBC patches also showed no
speedup on the hardware Linus uses, but it did show an impressive
(perhaps too impressive) speedup on other hardware:

But is it only me who worries that lots of people are running code
exposed to the internet that has obviously never even been run under
devel mailing list

  1   2   >