Re: How about firefox 3.6 in Fedora 12 ?
On Mon, Feb 1, 2010 at 8:10 AM, Mat Booth wrote: > On 30 January 2010 22:57, Mike Chambers wrote: >> On Sat, 2010-01-30 at 22:37 +, Mat Booth wrote: >>> Maybe but I agree with Braden: I don't think it's worth it. Seems like >>> a lot of extra work for not a lot of gain. >> Running a fully updated system, I upgraded to firefox-3.6 in rawhide >> today, and it only updated 3 (firefox, xulrunner, and some other that I >> don't recall) and everything working just fine. > For now... > > Really, you should be using Remi's repository. He has a build of 3.6 for F12: > > http://rpms.famillecollet.com/fedora/12/remi/x86_64/repoview/firefox.html > > But you mistook my comment. That comment was in reference to > maintaining two versions of xulrunner. These RPMS still appear to be using an internal copy of libogg and libtheora which is currently identical to upstream code which is already shipped in Fedora. (There are currently some patches for libvorbis shipped in Mozilla which are not upstream, but they introduce C99-isms (libvorbis is c90 clean for embedded platforms) and thus can't be directly applied upstream; I'm looking into that now. The other media stuff is probably too diverged from its upstreams to worry about right now.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Sun, Aug 15, 2010 at 8:31 PM, Bruno Wolff III wrote: > On Sun, Aug 15, 2010 at 16:44:29 -0700, > Matt McCutchen wrote: >> On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote: >> > Some web sites are indeed abusing JavaScript. >> >> > A web site is >> > not and should not be an application, an application is not and should not >> > be a web site. >> >> Just because you said so? Web applications bring enormous practical >> benefits to their users and administrators. > > My view is that they show only be used for applications when that application > is going to be used by someone with a trust relationship to the application > provider. For example when using Peoplesoft at work it makes sense, since > I trust my employer to not be trying to hack my work desktop. > > I think using javascript for pages meant to be used by the general public > is a bad idea. It encourages people who don't know better to enable > javascript for general browsing, which signifcantly increases the risks > to them for having credentials stolen or their desktop hacked. > > Instead things should be done server side, with style sheets or xforms. I don't think I'm going out on a limb in saying that limiting or handicapping javascript in the stock install is a non-starter. There are websites which make some use of javascript which are free software through and through. Even if your motivation is purely promoting free tools even breaking one of these would not be a good deal. As I understand it one of the Mozilla approved ways for integrators to change the default Firefox experience is through add-ons. There are a number of firefox addons which increase safety and privacy— tools like noscript, adblock, https-everywhere. (I was about to include ghostery in this list, but I see that it's not free software :( ). Including some of these addons in the default install may improve the security posture of fedora users and increase awareness of web-safety without wading into non-starter proposals like removing javascript. Moreover, by including these by default fedora would reduce the amount user conditioning for installing addons manually from assorted sources as firefox add-ons can be pretty horrific from a security and software freedom perspective as they can and do ship arbitrary binary code. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant wrote: > Do you REALLY believe that in a world where 90% of the desktops are > Windows, where 2 thirds of the browser market is shared by IE and safari > and where making governments to share public documents in a public > format rather than .doc/.xls/etc, web site managers would care if you > stop visiting their site ( which you probably NEED to access otherwise > you would not be trying to visit it in the first place) ? [snip] I don't agree with the suggestions here to restrict it, but I think the implications here sucks. Is it better to have a world where 90% is Fedora but every user has less freedom over their data and applications than they would in windows because they are only using Fedora as a really excellent remote terminal to web applications which give them no control over their data or the programs that they use? Disallowing compatibility with the world doesn't fix it but neither does ignoring the significant problems posed by non-free web applications and the enormous influence they will have over the fedora experience in the coming decades. Or in other words— for those who care about freedom making Fedora a first class platform for web apps is mostly just rearranging the deck chairs on the titanic— we're screwed either way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does X run as root?
On Fri, Aug 20, 2010 at 3:24 PM, Till Maas wrote: > On Fri, Aug 20, 2010 at 02:38:59PM -0400, Matthew Miller wrote: >> On Thu, Aug 19, 2010 at 06:49:33PM +0100, Matthew Garrett wrote: >> > > I think "run X as user Xorg if you're on KMS" would be a fine >> > > F15Feature to aim for. Ubuntu's been working on it too: >> > Of course, doing so just turns it from "Running code as X gives you >> > root" to "Running code as X gives you root the moment someone types in a >> > root password, even if they're on a different terminal". I accept that >> >> This sounds like yet another good argument for removing the need to ever >> type a root password. > > How does this make it better? Then someone would spy on the user password of > someone with sudo capabilities. This is an improvement because if Fedora removes "the need to ever type a root password" by simply allowing packagekit to give the user all the root abilities the user needs then the attacker doesn't need to wait around for the user to do something privileged, they can just ask packagekit as the user to do it for them. I'm sure this will save a lot of time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How many lost users is an acceptable loss in exchange for systemd?
In many of the recent systemd threads there is an underlying point which I think is on many people's minds but which I haven't seen called out. I think this is a generic issue, so it's a but unfair to single out systemd but it makes a good example. To say it bluntly: Any significant infrastructural change _will_ cost Fedora some users in the short term. The amount lost depends on the specific feature and the effort put in to minimize the bugs and disruption, — usually with enough effort and enough compromises and concessions the number can be made arbitrarily small but it will not be zero. This is especially the case for features which make the system more or less unrecoverable inoperable for 'normal' users when something goes wrong, but it's true more generally as well. And I do think that some loss is acceptable— without tolerating some loss Fedora simply couldn't move forward— no matter how wise or overdue a change is there will be bugs, differences in taste, and disruption. There are some people who are continuing to use Fedora only because learning SomethingElse™ is too much work but when Fedora changes and they'll have to learn either way Fedora's "advantage" vanishes to them. And, yes, the harm won't be equally distributed— it seems to me that Fedora has ignored quite a bit of harm because it didn't primarily fall on what the developer's considered a "typical desktop" (which, as far as I can tell, really means a particularly narrow set of laptop hardware with a particularly narrow set of users and use cases). Why Fedora keeps chasing a market which Ubuntu has undeniably won is beyond me— but nevertheless it's not acceptable to pretend that harms don't exist simply because they don't hit the one use case you care about most, not unless Fedora is willing to say that people running servers, developers, and other power users ought to use some other distribution and that Fedora doesn't care if it loses all of these users. Consider systemd— even if far more work goes into it I think we can admit that it will be very likely that there will be some users with some weird configurations which won't boot up with it. We can blame their weird configurations, hardware, and random packages as much as we like— but at the end of it some of these users are going to leave Fedora because of the change. Some administrators are going to hate the management changes and switch off Fedora as a result. We might all agree that they're lazy or crazy but it is what it is. These losses can be reduced by making systemd emulate the old stuff more accurately (at a cost to systemd's long term purity), by more testing, by providing fallbacks, etc. But some compromises aren't acceptable, no testing is perfect, and many people will never learn about the fallbacks. The same stuff could have been said about kernel modesetting. The sooner people admit this the sooner people can agree on what the acceptable loss level is... Without knowing the acceptable loss level it won't be easy to agree on a release criteria or agree on how much mitigating compromises are required to get there. Denying it or blaming other packages just makes the Fedora community blind to the risks, which is sad since many of them can be reduced and managed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: article on security of various linux
On Thu, Sep 9, 2010 at 9:45 AM, Neal Becker wrote: > This article: > > http://labs.mwrinfosecurity.com/notices/security_mechanisms_in_linux_environment__part_1___userspace_memory_protection/ > > seems to say that fedora is ranking poorly in deployment of various > userspace memory protection mechanisms. Is this information accurate? I asked about one point of this on LWN: Library randomization / prelink Posted Sep 8, 2010 18:26 UTC (Wed) by gmaxwell (subscriber, #30048) [Link] Anyone know how the library randomization is being counted? 3 bits for fedora doesn't sound right. Is the 3 bits the value for a system vs itself or for this system vs all other systems? To which I got this reply: Posted Sep 8, 2010 19:58 UTC (Wed) by kbad (subscriber, #61983) [Link] From the pax dev (gentoo-hardened list): "a note here: fedora uses exec-shield which maps libraries in two different regions: ascii-armor (lower 16MB) and the rest. i think what paxtest measured there is the former where the usable entropy is necessarily less than elsewhere and may not be representative of real life apps and their address spaces (not saying the whole ascii-armor region is worth anything for security though ;)" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
x86_64 as Fedora's primary platform
The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 1:58 PM, Stephen John Smoogen wrote: > On Mon, Sep 27, 2010 at 13:48, Gregory Maxwell wrote: >> The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) >> continue to promote i686 installs over x86_64, the result being that >> only a third of fedora users are on x86_64. >> >> When will the Fedora project begin recommending x86_64 as the >> preferred option on the relevant hardware? > > Well while many people have x86_64 capable hardware, 66% of the > systems have less than 2GB of ram installed on them. The gain of extra > registers is taken over by the amount of extra memory used. So I am > not sure pushing 64 bit will gain much beyond "why am I using so much > memory now?" messages. I agree that systems which are very short on memory will be happier with i386 but I don't think 2GBytes is at all a reasonable cut-off. None of the x86_64 desktops I have access to are currently using more than 1Gbyte (ignoring cache, of course). Only something like 11% of systems have less than 512MBytes, roughly 1/3rd with less than 1Gbyte. If you're not swapping x86_64 bringing increased performance is easily demonstrated, and has been previously demonstrated here... if there is any doubt on this point I'd be glad to run some more benchmarks to demonstrate it. E.g. On a random 720p video file (http://xiph.org/video/vid1.shtml) Theora decode is over 20% faster with x86_64 compared to i686 on the same hardware (X3360), even though libtheora can detect and use SSE2 at runtime. I admit that this is probably one of the bigger differences— the point is that the improvement is can be very non-trivial on CPU bound code that actually matters to users. On Mon, Sep 27, 2010 at 1:53 PM, seth vidal wrote: > i686 will run on x86_64 and i686 machines and on the overwhelming > majority of hw someone will happen to have. > > x86_64 will not. > > until i686 is uncommon (which is still not yet) I think we should keep > the default i686. I find it somewhat incomprehensible that Fedora has chosen to _completely exclude_ pre-P6 cpus and came fairly close to also excluding x86 systems without SSE2 (which are still being mass produced)— but Fedora won't promote x86_64 as a leading option when it only constitutes a majority of the target system. What is the thinking here? Is it really better to make Fedora not run at all on part of the installed base in order to force-fit the i686 builds as high performance options, simply because defaulting to the real high performance option will make the install process a little trickier for users on netbooks? On Mon, Sep 27, 2010 at 1:59 PM, Athmane Madjoudj wrote: > Most (if not all) Atom-based netbook are i686. Indeed, the netbooks have special requirements. The in-order atom CPUs alone benefit from fairly different compiler scheduling which is less than ideal for the extensively out of order cpus used everywhere else. The netbooks are also special in a number of other ways... I doubt there are many desktops out there with 1024x600 screens. Since the needs of netbook users are so specialized, why aren't they being directed to a netbook specific spin? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 3:26 PM, Frank Murphy wrote: > On 27/09/10 20:12, Gregory Maxwell wrote: > >> >> If you're not swapping x86_64 bringing increased performance is easily >> demonstrated, and has been previously demonstrated here... if there is >> any doubt on this point I'd be glad to run some more benchmarks to >> demonstrate it. > > For me inept brain. > You mean no swap partition? Ha. No. I mean so long as your working set is smaller than the amount of physical ram. Or in other words so long as your not frequently swapping things out to make room, e.g. the swap in/out counters in vmstat. On Mon, Sep 27, 2010 at 3:34 PM, Stephen John Smoogen wrote: > My laptop went into swap after about 4 hours of work from firefox, > thunderbird, and xchat. At 4 GB I find it pretty stable. It's not too difficult to drive firefox into using more than 3Gbytes of _virtual memory_, with the actual in use memory much smaller. On i386 this inevitably results in a crash, while on x86_64 it's fine— and even if the memory actually gets dirty at least you can swap it out. Very few applications handle OOM gracefully and yet on i686 it's not too difficult for a desktop grade system to exhaust the address space. Arguably the continued promotion of i686 is a stability issue. > On a longer state. Redesigning that page always causes a painful long > list of arguments as everyone wants to be on the top or listed. PPC, > KDE, LXDE, and s390 all come out of the woodwork and want a big link > on top (or lets randomize it to make it even!). So after the last > bikeshedding and my distro is bigger and larger than yours talk.. it > was decided to go with one that worked best on the largest install > base. As far as I can tell the x86_64 hardware probably already has the "largest installed base" unless you add all of it's installed base to i686 since x86_64 supports a compatibility mode. I don't believe that adding it makes a lot of sense since that kind of reasoning would have Fedora promoting x86_64 even when i686 was more or less completely extinct. Cheers! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 4:12 PM, Mike McGrath wrote: > FWIW, we have two measurements of x86_64 vs i686. > > Smolt: > 65% i686 > 35% x86_64 > > mirrors.fedoraproject.org: > 70% i686 > 30% x86_64 Right— it's clear that i686 is far more commonly installed today but a non-trivial part of that must be due to the fact that the x86_64 links are hidden. The smolt cpu stats (mhz, number of cores, vendors) suggests that a significant portion of these i686 installs are x86_64 hardware. Though I don't know of any way to gage this precisely. Does anything smolt gathers reliably indicate if the system is x86_64 capable? If so, could that data be made public? I would expect that the i686 install will remain the most common so long as that is what the Fedora project promotes. Drawing attention back to the original post for a moment "When will the Fedora project begin recommending x86_64"— I wasn't rattling so much for the change to happen now (although I think it should), as much ask asking when it will happen, or really what criteria will be used to determine if we've reached that point yet. I don't think criteria which can never be true (number of systems that can run x86_64 > can run i686) or which are nearly circular (existing installed versions; which no-doubt depends strongly on what Fedora chooses to promote) are all that reasonable. Cheers— -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 8:58 AM, mike cloaked wrote: >> Huh? Sure they are. > > Some people use nightlies for example - > Here there are no 64 bit versions that I am aware of? > > I do this when the stock version is somewhat behind even the stable > release from mozilla. eg in f12 the current thunderbird is 3.1.4 but > the current f12 version is 3.0.7, and similar for firefox. Yet this is > still a supported release - yes f13 is up to current stable releases > from mozilla for both of these. However in the mozilla filestore for > latest stable for thunderbird at: Mozilla only builds x86_64 for trunk builds: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ If you're not interested in the bleeding edge, why not run what Fedora provides? ...and if more people were using x86_64 Linux then perhaps Mozilla would bother building the other branches for it. [snip] > However in the future, say when f15 is still supported but f16 is > current, it may well be that it is more work to run applications such > as this that are more up to date than the Fedora packages either by > messing with multilib library install or building the application for > 64 bit from source. The traditional way to get future packages is to pull them back from later Fedora versions— though this doesn't always work, nor does taking packages from a third party. > There must be quite a few other examples where people will want to run > specific codes that are not built for 64 bit? To take the hassle out > of dealing with issues like this I install 32 bit and life is a bit > easier! Not fedora packages, however. Third party, especially binary only things... Sure. But the way to move forward there is to get x86_64 the default— the technical issues are solved, only market share will convince the stragglers. And besides, "Fedora is a center for innovation in free and open source software" and 1/3rd of Fedora users are already on it. Nothing is bug free— but Fedora's 64 bit support is about as close as anything available to me, and has been for some time. Advising caution 'until the bugs were worked out' might have been reasonable long ago, but not anymore. As far as I can tell the only big reason to lead with i686 is simply because if x86_64 is promoted some people will download the wrong version for their hardware and have trouble installing. It's a real concern, but I think that Fedora's commitment to innovation should take priority, as it has taken priority over small usability issues every time Fedora has updated some major piece of infrastructure to a new version. > However no doubt the best decision will emerge from the discussion? No doubt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wed, Sep 29, 2010 at 10:10 PM, Takanori MATSUURA wrote: > Hi Chen, > > For modules/libimg/png, mozilla products use aPNG which was rejected > by upstream. > http://en.wikipedia.org/wiki/APNG > > So we have to use internal png. > > For media/libvorbis, mozilla has custom patches in the source tree. > https://bugzilla.mozilla.org/show_bug.cgi?id=517422 > > Fro media/libvpx, I don't know well. However you are welcome to file > the issue to bugzilla.mozilla.org. Mozilla isn't always great about getting changes pushed upstream. I just committed the relevant patch they had outstanding against libvorbis to the libvorbis svn, though I'm not sure when we'll cut another official libvorbis release. (They also have a patch for building on Solaris— which seems to be due to not using the normal build system for libvorbis. I'm pretty confident that it's irrelevant for Fedora). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, Sep 30, 2010 at 1:09 PM, Christopher Aillon wrote: > On 09/30/2010 05:19 AM, Sven Lankes wrote: >> On Thu, Sep 30, 2010 at 06:37:33PM +0900, Takanori MATSUURA wrote: >> >>> If someone implement >>> --enable-system-libvpx >>> --enable-system-vorbis >>> --enable-system-ogg >>> --enable-system-theora >>> into the mozilla source, we can easily remove source for the >>> libraries. And Fedora will be happy. :-) >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=577653 >> >> Looking at how rigorous new packages with bundled libs are fought we >> should really stop shipping firefox and start shipping Iceweasel. > > I personally don't care what we call it. I'm not going to start > breaking funny cat videos just to meet packaging ideals on a deadline. > I'd rather deal with all you guys complaining on fedora-devel and in > fesco tickets than the influx of bugs if I started breaking shit. It's > bad enough that there are more bugs than we can handle. Besides, > Mozilla has a good track record of allowing system libs after things > settle down, and I have no doubt that we'll get these at some point. > > From Mozilla's perspective, they could: > > 1. Do what they are doing now, temporarily not allow a few new system > libs, waiting until they get banged into shape and *then* enable system > libs (down the road). > 2. Bang on the code in private and wait until it meets every Fedora > packaging guideline, etc, until committing to the upstream repository, > so we all get to wait for all of the cool shit that's happening. > > Please note that we're talking about pre-release versions of Firefox in > a pre-release version of Fedora anyway, so a lot of churn is to be > expected. We're almost certainly going to have to temporarily disable > and reenable a lot of other system libs during the beta cycles to get > builds out the door, just like we always do in rawhide. Not that I can > guarantee that the release version will have all the above system libs > enabled, but we'll know a lot more closer to FF4 and F15 release time. I yelled pretty loudly when Fedora first packaged libvpx because fedora took a _known vulnerable_ version which Mozilla and opera were patching around but where the upstream hadn't yet merged the fixes. Things are more mature now but there are still somewhat scary fixes happening, at least with the platform dependant code: https://review.webmproject.org/#change,603 Mozilla being a vector for the widescale exploitation would be terrible for their image— and also terrible for Fedora's, we really don't want to create our own version of the debian openssl rng bug. There really is a common interest here and the folks on the Mozilla side are better informed about the risks. The patches mozilla is carrying are visible as files in the respective directories here: http://mxr.mozilla.org/mozilla-central/source/media/ I'd suggest that fedora folks interested in the bundling help by making sure that the applicable fixes make it upstream. Even if Fedora were to ditch the trademarks you couldn't escape doing this work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, Sep 30, 2010 at 2:29 PM, Toshio Kuratomi wrote: > On Thu, Sep 30, 2010 at 02:22:36PM -0400, Toshio Kuratomi wrote: >> On Thu, Sep 30, 2010 at 01:29:38PM -0400, Gregory Maxwell wrote: >> > >> > I yelled pretty loudly when Fedora first packaged libvpx because >> > fedora took a _known vulnerable_ version which Mozilla and opera were >> > patching around but where the upstream hadn't yet merged the fixes. >> > > I don't see a note from you on the review bug, so I can continue to read > about this, where did you yell? > > https://bugzilla.redhat.com/show_bug.cgi?id=593879 https://bugzilla.redhat.com/show_bug.cgi?id=599147 and http://www.mail-archive.com/devel@lists.fedoraproject.org/msg08138.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
On Sat, Oct 2, 2010 at 1:34 PM, Paul F. Johnson wrote: > Hi, > >> "You shall not create images with arithmetic coding" is like saying "You >> shall not create images of the flying sphagetti monster." It's not up to >> Fedora to make this choice for me. > > It is though - you have chosen to use Fedora therefore have to live with > the decisions the Fedora legal people (I'm assuming they said no to > arithmetic coding) have said goes. The relevant patent expired last year. I believe the SUN OMS team had researched this extensively as they were using the JPEG arithmetic coder in their aggressively researched royalty free video codec design. If someone doing legal research on this needs more information, you can contact me offlist and I can connect you with people who have researched this topic and may be willing to provide some useful pointers. 2010/10/2 Björn Persson : > It's well known around the Internet that to achieve compatibility you should > be conservative in what you send and liberal in what you accept. Applied to > JPEG: Use only Huffman coding when encoding – except maybe if you know that > all > recipients can handle arithmetic coding – but support both encodings when > decoding. Absolutely. This is an excellent argument and I think is sufficient to justify the inclusion alone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, Oct 6, 2010 at 10:08 AM, Michal Schmidt wrote: [snip] > Of course. But there's in fact no disagreement, only looking at > different aspects of the same thing. > > Why do you think the copying takes place? Because the companies have > built a good reputation and brand, allowing them to increase profit. > > Good quality => good reputation => solid brand => better profits. > > Then copyists try to get better profits too without bothering to > build their own good reputation, by deceiving the buyers into thinking > the original company with good reputation produced their goods. > > I'm really quite surprised about this thread. Of all the stuff > often put under the confusing term "intellectual property" I expected > trademarks to be the least controversial. Exactly. I often describe trademarks as a kind of consumer protection law— but instead of using the blunt tool of government driven enforcement it relies on the existence of an interested party (the trademark holder) to provide the protection at their own expense with enforcement via civil law. This has advantages (it's very flexible, enforcement can be made to match the need, the public doesn't need to pay for it directly) and disadvantages (it suffers if the interested party is either not interested enough or too interested), but regardless it's pretty much something categorically different from, say, patents... which have no consumer-protective properties and which are very difficult to escape (compared to changing a package name/branding). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams wrote: > I noticed that ethtool is not in the default install anymore (probably > for a release or so, but I didn't notice it until now). Why is that? > It is the only tool that can show and configure a variety of network > device options, such as speed/duplex negotiation, wake-on-LAN, and TCP > offloading. There is support in the ifcfg-eth* files for calling it as > part of interface setup (don't know if that's carried forward to NM, > should be considered a bug in NM if not). mii-tool. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On Tue, Oct 12, 2010 at 8:01 PM, Chris Adams wrote: > Once upon a time, Gregory Maxwell said: >> On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams wrote: >> > I noticed that ethtool is not in the default install anymore (probably >> > for a release or so, but I didn't notice it until now). Why is that? >> > It is the only tool that can show and configure a variety of network >> > device options, such as speed/duplex negotiation, wake-on-LAN, and TCP >> > offloading. There is support in the ifcfg-eth* files for calling it as >> > part of interface setup (don't know if that's carried forward to NM, >> > should be considered a bug in NM if not). >> >> mii-tool. > > Does that work with all NICs now? I used to run into NICs that it > didn't handle (but ethtool did). I haven't looked at mii-tool in a > while though. > > In any case, that handles one thing that ethtool does (speed/duplex); > what about the rest? Also, AFAIK there's no nice hook to run mii-tool > (or anything else) in ifup-eth like there is for ethtool. I don't know— but it also won't let you adjust things like interrupt mitigation— which is essential for low latency audio over the network because lots of cards go into idiotic buffering modes at fairly low PPS rates and the latency shoots through the roof... (my use case) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wed, Oct 13, 2010 at 6:46 PM, Adam Williamson wrote: > On Thu, 2010-10-14 at 00:36 +0200, Kevin Kofler wrote: >> Thorsten Leemhuis wrote: >> > * Why haven't those that want iceweasel and icedove in Fedora not >> > simply invested some time and got them integrated into the repository?(¹) >> >> Because having both Iceweasel and Firefox in the repository, in addition to >> being stupid by itself, would also mean shipping 2 different versions of >> xulrunner (because there's where most of the offending patches live). >> >> And besides, it's not that we want Iceweasel, it's that we DO NOT WANT >> Firefox since it does not follow Fedora policies. Having both would not >> actually solve any problem. > > Proving that we can package Iceweasel and Icedove into Fedora and wind > up with workable software is a big step on that road, though. I think > making Iceweasel and Icedove packages and then floating the proposal > "switch from these guideline-infringing Firefox and Thunderbird packages > to these non-guideline-infringing Iceweasel and Icedove packages that > already exist and are tested" would get much more momentum than just > complaining that the Firefox and Thunderbird packages are infringing. Iceweasel as it currently exists in debian currently bundles exactly the same media libraries. (http://packages.debian.org/source/experimental/iceweasel — notice the lack of dependency on libvorbis,libtheora,libvpx,libogg,etc) It's facts like these that put the lie to the ridiculous claim that the media library bundling has much of anything to do with trademarks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski wrote: > The security role and rationale for the filesystem encryption is to > prevent the access to lost or stolen media, when you can't rely on the > mechanisms existent within the OS. The underlying device encryption > technology is not set up to keep track of who is accessing the data > after it is decrypted and made available to the system, as you correctly > point out. > > Such user-differentiated authorization is provided by the filesystem > access rights, ACLs and SELinux attributes. Note that unlike the first > two mechanisms, SELinux can protect the data even for systems with > compromised root---as someone said, SELinux can be configured so that > you can tell people "here's the root password; now break into my computer". > > What you are asking for improves security by adding additional depth, > but it requires a fairly intensive redesign and reimplementation of the > device encryption, so it befall on you to provide a good analysis and > justification of the tradeoffs. I don't think anyone here is asking for protection from root or anything as elaborate as a SELinux MLS configuration. I think that a small change in the default mount behavior so that the mountpoint encrypted is always owned by the user and mode 700— or if it were mounted under the user's home directory, perhaps with a checkbox (defaulting to off) on the password dialog "Make this volume available to all users on my system", would better meet the user's expectations of how an encrypted volume should behave. There are a lot of neat security things which could and should be done. Why can firefox upload my ssh private key file to random websites? Etc. But this case isn't one of those SELinux rocket science cases, it's simply a matter of using regular unix security in a way that reduces surprises. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III wrote: > This is where we should be going. Encryption is really irrelavent. The issue > should be if a removable device is inserted, who should have access to it > if it gets automounted. I would expect encrypted and unencrypted devices > to get the same treatment. The encrypted devices do already have a pop up, > so maybe that makes it not as much effort to ask a question when the device > is mounted. But I don't see otherwise why one would want to treat encrypted > and uncrypted removable devices differently. We don't know which of multiple users plugged the device in but we know which user provided the key to decrypt the device. The existence of encryption shows that the user may care more about the confidentiality of the data, and there is less of an previously existing "installed base" of expectations about how an encrypted volume works when you plug it in. If we wanted to get fancy (e.g. go beyond just a change in the default modes) additional users could authenticate themselves to an already mounted encrypted volume one at a time by providing the key. ::shrugs:: -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On Sun, Nov 7, 2010 at 1:57 PM, Stephen John Smoogen wrote: > Ok there are several different "cold boot attacks". The one I think > you are talking about is the removing memory from the system and > reading its contents with a special board. The kernel does not [snip] Not even with a special board, ... > In the end, if someone has physical access to your system, you are not > going to be able to completely defend against a cold boot attack. > Encrypting the drive and keeping it reasonably secure is about all you > can do without having hardware that helps. Here is the attack: Your system is running with nice secure encrypted drives, no console access (or a locked screen on a laptop). The attacker inserts a bootable USB key and hits the power switch. System reboots into the USB key, it retrieves the cryptographic keys for reading your disk from memory, then copies whatever information it likes. This works even when a fairly high percentage of the key bits are corrupted because the bits of the AES key schedule have simple linear relationships with the key, so it functions as an excellent error correcting code. For some common situations like protecting your laptop with disk encryption this attack completely invalidates the protection, at least against a moderately savvy attacker. The software for performing this attack is available from here: http://citp.princeton.edu/memory/code/ This is not merely a theoretical weakness. It is easily executable by anyone without the need for special hardware. Without special hardware (like support for CPU-internal key management, CPU support for encrypted ram) this attack is impossible to close completely but small improvement could easily be made which dramatically increased the difficulty of the attack. * The kernel could avoid leaving confidentiality critical data laying around for long spans of time, long term keying could be stored in areas of memory more reliably overwritten at reboot * Bioses could be modified to zero-ize memory at start * Ciphers with linear key-schedules could be avoided (unfortunately everything from the AES contest is bad at this, because the contest pressure to work on low memory devices and small message sizes made everyone use very cheap initialization; blowfish is an example of something which I think is mostly free of that particular weakness) * Userspace could freeze all access to encrypted volumes when the screen is locked and toss the keys. (This is most reasonable when the volume password and the user's login password are the same) There were patches posted to the Linux kernel to reduce the exposure from this kind of attack: http://lwn.net/Articles/334747/ but unfortunately the author and the LKML didn't get along and the patches were never merged. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
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
ignore.
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
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
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 restriction). [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 concerns. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I can not import the browser cert, please help.
On Sat, Feb 27, 2010 at 1:00 PM, Dirk Gottschalk wrote: > Hello, > > i can not import the browser-cert from fedora in to mozilla. > Mozilla says that it can not be imported for unknown reasons. > > Can somebody help me? Disable the torbutton add-on. No kidding. failing that, try pk12util -i certfilename.p12 -d ~/.mozilla/firefox/randomcrap.default/ (replace cerfilename and randomcrap with the actual values). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
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
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A software center for Fedora
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: http://people.xiph.org/~greg/packagekit.png 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A software center for Fedora
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
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: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335#c8 (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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 11:35 AM, Jesse Keating wrote: > On 11/9/10 8:23 AM, Andrew Haley wrote: >> I've seen the responses on the Wayland list, and it's always "Wayland >> isn't intended to do that." So, there's no point raising objections >> there. >> >> The risk is that Wayland gets developed and a bunch of key >> applications in Fedora get broken. The Wayland guys are not the >> people to talk to, since network transparency isn't on their radar, >> from what I can see. > > What makes you think that carping about it here will have any effect, > particularly because NOBODY HAS PROPOSED WE USE WAYLAND yet. I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers "If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install". If that is indeed the position of the Fedora community then it would carry a lot more weight in someone's planning than individual people whining on the wayland list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jackson wrote: > On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: > >> +1 for bringing these points up. No offense to krh (because it's nice >> technology) but you can pull my genuine networked applications from my >> cold dead hands. I agree that I see this ongoing trend to move toward >> things that are fluffy and pretty at the cost of flexibility. > > No. You see the system you know and understand being replaced by one > you don't. You have an emotional attachment to the old system because > it gives you a feature you like and the dozens of problems with it > aren't important to you. And you claim that the replacement is less > flexible because you don't understand or don't want to learn the new > thing. I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. So, > You are, in short, scared. ... I think this is a rather unfair characterization. Perhaps the concerns that people have are misplaced—— perhaps a switch to somehow wayland doesn't imply a loss of reasonably functioning network transparency. If so, then clarifying it beyond your "gtk/qt" will offer both X and wayland would be helpful. Especially since providing both TUI and GUI administrative tools hasn't really panned out in practice. In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect. [snip] > Remoting a wayland application is _trivial_. Either to an X or to a > wayland view system. It's hard to make wayland remoting less flexible > than X over the network, since the natural remoting level (surface > updates) is basically stateless unlike X's sixteen complete IPC > interfaces, and unlike X you're actually guaranteed that the window > surfaces exist and have meaningful content. So you get the > long-lusted-for "screen for X" almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn wrote: > On 11/09/2010 06:12 PM, Gregory Maxwell wrote: >> I've mostly been watching here and I think people have been fairly >> clearly about their concerns: Network transparency is important to >> them, and they understand that the wayland message is that it will not >> be supported. This message has been clear enough to me here and >> elsewhere— with people arguing things like applications which need >> network transparency are all now web based. > > You are mis-interpreting the message probably because you are not a > developer and as a result don't know how software is designed in layers. > Wayland handles the visual aspects of the desktop. Networking doesn't > belong there. A remote app layer will sit on top of Wayland and deal with > the communication between both ends. Nice way to assume. Its pretty likely that you use software I wrote every day. So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated. What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications. If is so clear-cut for wayland then why can't a clear message be provided? Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement. Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent. I'm perfectly capable of understanding a statement like "Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you." [snip] >> In any case, I can't see that there has been any real concern raised >> about _change_. Fedora is full of change. People are raising and >> arguing specific concerns about the nature of the changes. Please >> treat your list co-habitants with a little more respect. > > Then why are people already calling for the rejection of Wayland even > though Wayland is still far from being finished and hasn't even touched > Fedora yet. > > raising concerns != screaming the sky is falling Well _I_ certainly didn't intend to call for a rejection of wayland— it seems to be far too immature to even talk about rejecting it at this point. But I think Fedora ought to make clear that network transparency is requirement. It seems that at least a few people in this thread don't believe that it is, and I think that ought to be cleared up sooner rather than later because I'd hate to hear that a lot of effort was put in building a system that won't really meet the needs. If the need for network transparency is already well understood then I don't think there is much more to discuss. [snip] > X will run as a Wayland client. That means all applications that support X > will be able to run remotely without change. Since QT and GTK both run on X > and virtually all apps out there are programmed to use QT and/or GTK for > most people nothing will change in the next couple of years. This is exactly the sort of non-comforting communication that I was complaining about above. The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions. You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality. > That's why it's so hard to understand why people are already bringing out > their torches and pitchforks over this. Keep your windowing system out of my network transparency ;) > Now let's assume Wayland is really successull. In that case people will > want to get rid of X altogether and then you'd also lose the remote app > support of X and in that case you obviou
Re: Fixing the glibc adobe flash incompatibility
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? [snip] 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: http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278 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 valgrind? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 10:03 PM, Chris Adams wrote: [snip] > shouldn't be done in a "stable" release of glibc. Is memcpy called > often enough (and on large enough blocks) that this change makes a real > performance difference (not just on a synthetic memcpy benchmark)? Most code is not performance critical. However, performance critical code is performance critical. Memcpy bottle-necked workloads aren't that uncommon. If you've got one you want every piece of memcpy performance possible, if you don't have one then you won't care. Every single performance thing is like this. They add up. If Fedora wanted to carry a patch against GLIBC it could carry one that crashed any application that called memcpy with overlapping inputs. Every one of these bugs would be fixed right quickly. (FWIW, I think the old memcpy would also fail on overlaps, but it would tend to corrupt the ends and only if the ends were within four bytes of each other and the length was one less than a multiple of four or something like that). It's probably a reasonable guess that anything using memcpy incorrectly has other errors arising from a failure to understand and follow the relevant APIs. Although it seems like an easy mistake to make— I've valgrinded a lot of code and never seen the valgrind warning for this. I don't think it's actually common. It might be useful to first measure before worrying too much about this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
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 [snip] # echo 2 > /proc/sys/vm/overcommit_memory # echo 0 > /proc/sys/vm/overcommit_ratio :) (and good luck with that!) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New celt build broke jack-audio-connection-kit...
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 util.py:247: libcelt0.so.1()(64bit) is needed by jack-audio-connection-kit-1.9.6-4.fc16.x86_64 >>> >>> 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New celt build broke jack-audio-connection-kit...
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 library. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Delayed encrypted partition mount
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sun, May 9, 2010 at 4:15 PM, Ryan Rix wrote: > Here is how I see this: The user installs their system for the first time, > they set their clock using NTP while they have the connection to the > internet when they installed their packageset/updates. Now they have an > accurate clock. > > How much drift can happen that each and every time they connect to the > internet, even if it's only for five minutes, would they need to resync > their clock? I have NTP disabled altogether on this machine, and since > I've installed it, it's still within about 5 seconds of my mother's > Windows machine which _does_ have ntp disabled. The amount of drift you may see is highly dependant on your hardware. A mere 1% frequency offset will gain or lose almost two hours per week. Arguably a system which drifts unacceptably is broken yet depending on your definition of unacceptably all of the available PC hardware is broken. And a constant frequency offset like that is trivially fixable. My last laptop lost a minute or two per week of uncorrected operation. At the time I was travelling a lot— and ending up habitually a late for a conference calls would remind me to unwedge it. The current laptop has, fortunately, only lost 2 seconds since Friday. Two headless systems of mine with "good" clocks in a temperature controlled environment show drift of 16 and 37 ppm (0.7 and 1.6 minutes per month respectively). A typical decent crystal oscillator simply running 10 deg C off its design temperature might be ~20 ppm off on its own. > I find that having NTP enabled in most cases for mobile systems is simply > unnecessary; there is a large (I would say upwards of 95% in my most > unscientific guessings) chance that these users aren't going to be doing > anything which requires their clocks to be synced with any amount of > precision. And if they are, they should _know_ that and be able to set up > a tool (whether it is NTP or Crony) themselves. > > Imo the use cases for having a constantly synced-to-the-second clock are > minimal at best. "I find that having non-root accounts enabled in most cases for mobile systems is simply unnecessary"(...) But really— having accurate time is important for all systems: Have you never had the experience of trying to debug a networked system only to eventually discover that there was a few seconds clock skew confusing your troubleshooting? At least in my world there are increasingly only two kinds of machines: mobile devices and headless servers, in that context what you're saying is that only servers need correct time, and I think that is quite wrong. Errors at the level of minutes are easily accumulated on common hardware and will impact human affairs. Sub-minute errors will frustrate technical troubleshooting— confusing the mutual ordering of events between systems even when the timestamps look quite different. An inaccurate clock even reduces user privacy on the internet as it makes hosts more easily distinguishable when the client's time is available over the network. If timekeeping really hard to fix on the lossy hardware we use I might buy an argument that fixing it wasn't worth the cost, but fortunately it is easily fixed to sub-second levels by running a simple daemon. Though, unfortunately, the NTP package will often fail to do anything useful when used on the increasingly common configurations with highly intermittent network connectivity. Perhaps you may not care about these things— but other people do for good reason, and you ought not oppose their efforts to advance the usefulness of the system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: web-m and Fedora 14
2010/5/20 Conan Kudo (ニール・ゴンパ) : > It's too bad that we can't say that Fedora 13 has all these cool things. > Fedora would get some considerable notoriety for being the first to fully > support it. Then again, we cannot fully support it for HTML5 since Firefox > doesn't have it... And Chromium is still not in the repositories. That > leaves only the WebKitGtk+ based browsers that use GStreamer. Nevertheless, > it would be great to have Fedora 13 be the first to be able to create > .webm files. It's still really _raw_ at this point. There is a reason that all the example stuff for this is in development and preview builds. The library can only be built as a static lib righ now. There are what appear to be security relevant bugs getting fixed. It also needs some significant performance improvements before its useful at high resolutions (1080p decode of the "parkjoy" clip on my 2.8ghz x86_64 quad core is not realtime using all four cores :( ). The vp8 team at goggle had externally imposed deadline, and we know what those do to software quality. Just drop it in the repos post release once it's stable and fast enough to do something useful. Until then there is a lot of integration work needed, but shipping unfinished work won't make it happen faster... it'll just make life harder in the future when people are stuck working around the bugs in early versions that were widely deployed before they were ready. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, Jul 8, 2010 at 3:43 AM, Jakub Jelinek wrote: > On Thu, Jul 08, 2010 at 12:54:35PM +0530, Rahul Sundaram wrote: >> Do you plan on doing a mass rebuild? > > I don't think it is necessary, at least not for the reason of a compiler > upgrade. The mass rebuilds are usually done when we have some toolchain > or rpm feature that we want to push into all packages. I watched the thread to see if anyone else would mention this... But I think it's undesirable to ship packages that couldn't be recompiled under the system compiler. ... and without doing the mass rebuild you won't know of the potential build failures. Not by itself a killer reason— there are many other possible causes for a package not being buildable on an installed system. But it's a factor which should be considered. Also— I think it is undesirable for a minor security fix to change the compiler a package is built with during a release... while the security fix may have been carefully validated as safe the compiler switchover may have more significant unexpected side effects. If programs start failing due to security updates, users stop running security updates. If not doing a mass rebuild would result in this happening, thats another consideration. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Sat, Jul 10, 2010 at 7:06 AM, drago01 wrote: >>> - Helper routines used by yum to extract dependencies >>> >>> - X-Windows server and libraries used for 2D and 3D display such as >>> opengl, compiz, etc. >> and ghostscript, poppler, ... >> Everyone will easily suggest Firefox and OpenOffice.org. > Not sure about firefox but atleast xulrunner and thus spidermonkey > should help any app that uses them. Why have some regular users leave oprofile running for a bit and find out what is actually consuming cpu cycles on a typical fedora desktop? (I don't really have access to any of those, regular users, or I'd post numbers instead of this suggestion). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Fri, Jul 30, 2010 at 1:30 PM, Rahul Sundaram wrote: > > On Fri, Jul 30, 2010 at 10:50 PM, Bill Nottingham wrote: >> >> Everything I've seen you ask about repos stems from an apparent end goal >> of 'get rpmfusion onto Fedora systems as much as possible', and consists >> of attempting to either have Fedora make changes to accomplish that, or >> to language lawyer around the existing guidelines. It's tiring > > You have to be in engaging in very selective reading or exaggerating > dramatically. Even in this thread, I have talked about a standard way of Rahul, Bill's characterization of your responses seems more than fair to me. Many months back I began drafting a letter intended for RedHat legal folks raising a concern that your activities were a potential liability. ... but I ended up not finishing it because it made me feel like a tattle-tale. Regardless, — you have frequently come off as presenting a wink-wink-nod-nod kind of approach towards these issues, and I think it reflects poorly on the fedora project. I hope you'll discontinue it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Group Calls For Boycotting Systemd
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 become. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bundling of jemalloc
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 > http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries)? 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: urandom vs haveged
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin-otr security update pushed - please test and give karma
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x32 abi support?
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 be. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
*countable infinities only
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. http://mjg59.dreamwidth.org/12368.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 Freedom"s 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 install. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
*countable infinities only
[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 capability. > 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 > distinction. Access to cryptographic signing keys is a technological restriction. Requiri
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Thu, May 31, 2012 at 12:22 PM, Peter Jones wrote: > The argument that it's a security effort is bolstered in many vendors eyes > by the existence of attacks in the wild which Secure Boot would prevent. I'm not aware of any attack _objectives_ (as compared to methods) which this would prevent, at least not without locking down all the code on the system instead of just the kernel and bootloader. Yes, some malware exploits insecure kernels to screw with the boot environment to prevent its removal. But if you take that away the malware will just modify the first piece of unsigned code to perform the same attack at every boot. If the first piece of unsigned code runs before software update the malware can still prevent updates from defeating it. If the kernel was secure to begin with (no boot time userspace exploit) then permissions in the kernel are enough and you don't need secureboot. > If you see a legal challenge to MS requiring secure boot to be enabled with > their keys in order to ship systems with their trademarked logo on it, > you're at your leisure to follow through on that. I'll make no attempt to > stand in > your way. I look forward to keeping track of your progress on this matter. Fedora's participation would substantially undermine both claims on anti-competitive and tortious interference grounds. I can only accept that the legal options have already been considered and were regarded as non-viable even absent Fedora's actions, but it's a little unfair to say "so you do it." here. I think it would be more accurate and honest to say "We've got better lawyers than you do, and we've already considered this and currently consider it non-viable for reasons we can't discuss in public— so much so that we're willing to forever undermine some possible arguments by going along with this." On Thu, May 31, 2012 at 12:42 PM, Miloslav Trmač wrote: > BIOS passwords. (Yes, it can be reset on many machines, but that's a > property of the machine, not of the design.) If I have access to the hardware I can just replace the whole motherboard. On Thu, May 31, 2012 at 12:42 PM, Miloslav Trmač wrote: > I can't see that this is a freedom issue. You are absolutely not > _forced_ to use the system this way. One freedom Fedora provides is the freedom to fork and make respins, without asking permission and without making them any less good (e.g. not like the old SUSE thing where the installer was non-free, or the old ubuntu thing where the distribution build infrastructure was non-free). If I make a fork of Fedora post SecureBoot my fork will be less compatible and harder to install the moment I adjust the binary to change the trademark name, much less make any real change. You may not thing this freedom to stand as technical equals is very important— but I counter that many people rationally believe the freedom to modify the software you run is not very important either. If it really was a non-issue Peter Jones wouldn't have just written: "Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines." The corollary to this is that "Next year if Fedora implements this, Forks and Respins will not be installable by the majority of users on the same hardware where Fedora runs". On Thu, May 31, 2012 at 11:59 AM, Peter Jones wrote: > You see why maybe that comes across as a bit of a fib? I'm not saying > you're > a bad person or something, but you appear to be reacting emotionally without > fully thinking through what you're saying, and as a result overlooking > things and contradicting yourself in an embarrassing way. You may want to do > some more sleeping on it. Well, I forwarded you some of the private discussion I was involved with which I felt supported the position I took that this wasn't seriously a matter for public discussion. You don't agree with my interpretation, and I don't consider you crazy for not agreeing with it. While airing Fedora governance dirty laundry in public isn't my goal, I wanted to at least make some comment here in my defense. My reading skills are not defective, and I'm not trolling. I was emotional about this 12 hours ago, but now I am responding in the hopes of increasing awareness. I know the page said that said that it wasn't done. But in direct contradiction to that I was told, to the best of my ability to understand, that this was going to be presented fait accompli, and that it would not be put to a vote before Fesco because doing so would simply be pretextual. Perhaps internal background to which I am not privy makes the nature of the pretext seem more charitable to others— that it would only be pretextual because everyone relevant has already been convinced that this best— and that it's not because they don't value freedom as much or because they're already too committed to this path... But I was not being careless, emotional, or dishonest to present this exactly a
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 because:" 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
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 > small. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 > transient. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 behalf. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 >> unacceptable. > > 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: http://people.xiph.org/~greg/openssl/ > 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 okay? 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 position. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 > notification. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 time. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 bootloader/kernel. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 > Windows. 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 > alienate > pretty much the entire OEM community for Windows add-on card drivers, pretty > much all major enterprise customers, and all computer science departments > that > 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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. ::shrugs:: How can we know our strength if we do not try? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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. ::facepalm:: 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
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 relevant. 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 systemd. (And the "you can manually force it", seems not much of a consolation to me— since that will be untested, unsupported, and very likely non-functional.) 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
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 > distro. > 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 complain. 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: http://www.gnu.org/philosophy/right-to-read.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
