Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram methe...@gmail.com 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?
rant On Fri, Sep 30, 2011 at 8:53 PM, Kevin Kofler kevin.kof...@chello.at 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. /rant -- 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 mzerq...@0pointer.de 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 cmad...@hiwaay.net 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 p...@city-fan.org 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 rc040...@freenet.de 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 lin...@fedoraproject.org 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 bernd.str...@gmail.com 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: Firefox 4 for Fedora 14?
On Fri, Jul 30, 2010 at 1:30 PM, Rahul Sundaram methe...@gmail.com 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: Javascript JIT in web browsers
On Sun, Aug 15, 2010 at 8:31 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, Aug 15, 2010 at 16:44:29 -0700, Matt McCutchen m...@mattmccutchen.net 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 wo...@nobugconsulting.ro 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 opensou...@till.name 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 ndbeck...@gmail.com 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 smo...@gmail.com wrote: On Mon, Sep 27, 2010 at 13:48, Gregory Maxwell gmaxw...@gmail.com 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 skvi...@fedoraproject.org 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 athma...@gmail.com 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 frankl...@gmail.com wrote: On 27/09/10 20:12, Gregory Maxwell wrote: snip 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 smo...@gmail.com 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 mmcgr...@redhat.com 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 mike.cloa...@gmail.com 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 t.mat...@gmail.com 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 cail...@redhat.com 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: Arithmetic coding in Fedora libjpeg (bug #639531)
On Sat, Oct 2, 2010 at 1:34 PM, Paul F. Johnson p...@all-the-johnsons.co.uk 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 bj...@xn--rombobjrn-67a.se: 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 mschm...@redhat.com 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 cmad...@hiwaay.net 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 cmad...@hiwaay.net wrote: Once upon a time, Gregory Maxwell gmaxw...@gmail.com said: On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams cmad...@hiwaay.net 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 awill...@redhat.com 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 przemek.klosow...@nist.gov 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 br...@wolff.to 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 smo...@gmail.com 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: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jackson a...@redhat.com 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: remove polkit from core?
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. More on the subject— in this brave new polkit JS world, when an administrator is considering upgrading their Fedora (or even some packages), what tools will they have to validate that their local JS actually works at all much less produces the desired behavior? I don't see any tools or documentation to facilitate that.It seems to me that adding a bunch of unsound programmatic configuration which can't reasonably be used by the end users due the overhead of keeping up regular fedora churn, especially absent good validation tools, is not a productive change relative to just baking in the additional logic and exposing it via basic configuration switches. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On Wed, Dec 19, 2012 at 10:40 AM, Bruno Wolff III br...@wolff.to wrote: In some cases you can get DSO linking errors when you don't explicitly link to those other packages. People building from source might not care, but this can cause problems for official builds. Can you elaborate on this or point me to where I can learn more? That is absolutely counter to my understanding. Consider: What happens if you have libfoo 1.0.0 which itself uses -lbar ... and later upgrade your system to libfoo 1.0.1 which itself is -lbar -lm (and is API/ABI and functionally identical). If I understand you correctly you're saying that now random -lfoo users which themselves make no use of -lm will now randomly fail. I believe this is incorrect and would be a terrible problem if it were true. AFAIK, you should only link your actual direct dependencies. If they have their own dependencies the dynamic linker will handle it, and anything else leads to madness. Am I full of it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On Wed, Dec 19, 2012 at 11:42 AM, Adrian vk4...@bigpond.com wrote: This attitude is why people leave redhat for debian/ubuntu, get fltk right and the rest will follow. We have tested already. Adrian, no disrespect intended— but I believe you are making a mistake here. It looks like package you're having trouble linking has incorrect parameters and just happens to work on ubuntu due to leakly pkgconf linker flags— it's not exposing its own direct dependencies and the correct solution is to fix it, not fltk. While I'm possibly mistaken due to some subtle detail of how the FLTK headers are setup I think that is unlikely. Everyone working on Fedora cares about doing the right thing— and helping the packages Fedora packages do the right thing. The tone you're taking is unnecessary insulting regardless of how correct you are... but when that kind of tone is combined with being incorrect it contributes to an environment where developers justifiability have low regard for some user complaints. Since people care about doing the right thing the tone isn't required nor is it helpful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On Wed, Dec 19, 2012 at 11:53 AM, Dan Williams d...@redhat.com wrote: It's the other way around. If libfoo 1.0.0 linked with -lbar and -lm, and then you upgraded to libfoo 1.0.1 which *no longer* links to -lm, now stuff that links to libfoo might fail if those things did not specifically request -lm themselves when they were built, and they need it. Ah. I read your statement backwards. I think we're in agreement. Everyone should (really, must) link their own dependencies explicitly, and pkgconf style config lines should generally only list the library itself to avoid creating a situation where the caller fails to correctly identify its dependencies and doesn't know it. But maybe fltk intentionally does something inadvisable here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Mon, Feb 1, 2010 at 8:10 AM, Mat Booth fed...@matbooth.co.uk wrote: On 30 January 2010 22:57, Mike Chambers m...@miketc.net 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: Fedora/Redhat and perfect forward secrecy
On Fri, Sep 6, 2013 at 2:31 PM, D. Hugh Redelmeier h...@mimosa.com wrote: | From: Reindl Harald h.rei...@thelounge.net | Date: Sat, 24 Aug 2013 11:38:21 +0200 | https://bugzilla.redhat.com/show_bug.cgi?id=3D319901 | | looks like Redhat based systems are the only remaining | which does not support EECDHE which is a shame these | days in context of PRISM and more and more Ciphers | are going to be unuseable (BEAST/CRIME weakness) It might be the case that the NSA has their fingers in these ECC standards. Here's a Schneier article worth reading: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance In it, he recommends (among many other things): Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. It could be (by accident) that Fedora is more secure due to patents! The P-256r curve commonly used for ECDH the web has it's parameters generated by a nothing-up-my-sleeve CSPRNG approach. I doubt Bruce was speaking of that... it he was, I think thats a pretty audacious claim that requires some justification. Regardless, I think that argument would be an ignorant one: Approximately no one runs non-ECDH PFS on the web: it's insanely slow and it breaks clients. The choice is not between ECDH and RSA based PFS, the choice is between ECDH and no PFS at all. Right now Fedora webservers have no PFS at all. This can not be argued to be an improvement. -- 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: Fedora/Redhat and perfect forward secrecy
On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters p...@nohats.ca wrote: For the client, clearly CPU is not the limiting factor. For regular TLS servers, this should also not matter. For fully loaded TLS servers or TLS accelerators, the factor 3 on the CPU load will matter, but we're talking clusters of machines here. Dropping in a few extra machines shouldn't be that hard to give your patent-encumbered endusers PFS. The difference between DHE and ECDH in TLS is a difference of supporting supporting about 3,000 connections per second and supporting something like 800 connections per second (somewhat vague numbers, opeenssl speed won't bench DH apparently, it's somewhat slower than RSA encrypt due to the exponentiation by large secret values). And this is comparing apples and oranges 256bit ECDSA (conjectured security involving a best attack 2^128) against DH-1024 (only 80 bit conjectured security). Comparing with DH-1024 is sort of silly because people do not consider 80 bit security adequate anymore. The comparison with 3072 bit DH is down to more like 200 connections per second. But again, and sorry to reiterate but it seems to be have been missed: ~No one actually supports the old DHE PFE, and offering it breaks some clients. So regardless of the speed concerns, a choice to not support ECDH is a choice to not have PFS at all, at least on public facing webservers. Ignoring the obvious legal (and now potential backdoor) problems with ECC is also not very educated. I am certainly not ignoring legal concerns. While there are some patented EC cryptographic techniques, the basic infrastructure including ECDH over prime fields was first published back in 1984 and is not patentable. The IETF has published an extensive RFC covering the foundations of ECC which carefully shows to-old-to-be-patentable direct citations: http://tools.ietf.org/html/rfc6090 If Redhat is aware of a specific patent concern here, they're keeping it secret from the public. The continued claims that there are legal issues here behind basic support really don't make a lot of sense, especially considering the functionality in RHEL. (I would also note that the support in RHEL somewhat oddly support _only_ the parameters from the NSA, which doesn't quite play into the expressed concern about backdoors) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Sep 9, 2013 at 11:46 AM, Paul Wouters p...@nohats.ca wrote: [not speaking for Red Hat] You seem to believe only valid legal claims can put Red Hat in court. Of course not. Though I'm not aware of anyone making any claims at all over basic non-specially optimized ECDH on prime fields. Perhaps RedHat is, though if certicom/rim is out patent trolling on the basic stuff it would be a shame to keep it a secret: They should take the goodwill loss they deserve if they're going around claiming to own techniques published in the mid 80s. You're going to have a lot of software to remove if the _possibility_ of someone putting RedHat in court is the bar here. There are a _LOT_ more patents on compilers than on elliptic curve cryptography. Or just patents on simple arithmetic optimizations, lets see US6073150 assigned to Sun. This one patents computing the absolute value of a signed number using masking by sign extension: E.g. Set mask = x(sizeof(x)*sizeof(char)-1); absx = (x^mask)-mask. Oh looky looky, GCC in Fedora 19 on x86_64 compiles int x; x = abs(x); to this: sarl$31, %eax xorl%eax, -4(%rbp) subl%eax, -4(%rbp) Good thing nothing in Fedora uses abs() and that Sun's patent's would never be held by a potentially hostile company so you don't have to depend on the fact that this technique was published eons before the patent (http://web.archive.org/web/19961201174141/www.x86.org/ftp/articles/pentopt/PENTOPT.TXT), since that the invalidity of the claim can't be ensured to keep RedHat out of court. ... And this is an example where we actually do the stuff that is patented. I do not believe there are any granted but invalid patents that would preclude using basic ECDH over prime fields. Maybe there are and RedHat has heard of some, but if so the world would certainly like to know that someone actual had a concrete risk here and this wasn't someone just pattern matching ECC = Patents ZOMG! in a way that they don't go Compilers = Patents ZOMG!. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
OpenH264 in Fedora
Greetings. Cisco has announced that they will be releasing an implementation of a BSD licensed H.264 (baseline profile) encoder and decoder, along with offering download of binaries of it under Cisco's licensing umbrella: http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc/ The intention is that any parties capable of obtaining and running the provided binaries (and they intended to be maximally inclusive of which platforms they build for) can have a fully licensed implementation of H.264 at no cost. This is especially relevant for the new WebRTC standard because the IETF is in the process of deciding which (if any) video codecs will be (the minimum) mandatory to implement for conformance with the specification. There has been a strong push to establish the royalty-free VP8 codec as MTI, and an equally strong push (primarily by vendors of legacy communications equipment with compatibility concerns) to establish H.264 (and not VP8) as mandatory to implement. The release of properly patent licensed gratis source available downloadable binaries has removed the strongest pragmatic arguments of the parties pushing for VP8 over H.264. (We _can't_ conform to the spec if it mandates H.264). It has been argued that no viable platform for WebRTC which cannot support H.264 already *and* cannot use the OpenH264 library exists or is likely to arise: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09312.html I personally believe it would probably be helpful to the discussion if Fedora is able to reach a (preliminary?) decision on if OpenH264 (as described) will be able to be used by Fedora systems (e.g. by having something analogous to codec buddy go install the codec to give all Fedora systems H.264 support) in order to provide feedback to the working group. If a decision to mandate H.264 in WebRTC means that Fedora systems would be unable to comply with the specification, that would be unfortunate. The rtcweb WG session which will discuss MTI video codec will be on Thursday the 7th at 13:00 pacific. As usual the meeting will be streamed and anyone can participate remotely via Jabber (rtc...@jabber.ietf.org), but feedback can be provided at any time via the mailing list (and it's probably best to comment earlier rather than later, links at http://tools.ietf.org/wg/rtcweb/). -- 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: OpenH264 in Fedora
On Mon, Nov 4, 2013 at 9:28 AM, Bruno Wolff III br...@wolff.to wrote: The issue for RTC is that we could be using a royalty free codec, such as VP8 instead. Accepting the binary makes it more likely that h.264 will be made mandatory to implement, which means any company not wanting to implement VP8 can always point to h.264 being mandatory as an excuse not to support VP8. Conformance with the specification may require the implementation of H.264 if the decision to make H.264 mandatory to implement. This means that those who care about conformance (e.g. those responding to RFPs) would need to deal with the consequences. Many people here have expressed the sentiment that Fedora would be unable to utilize this option. This is stark contrast to the claims made to the working group so far. If it is the case that fedora will not utilize this option (or another to obtain h264 support) and you care about avoiding an outcome where Fedora is unable to claim conformance with the spec, then someone probably ought to comment about this to the working group. Commenting to the WG list may not change the working group's outcome, commenting here surely won't. Another thing to worry about is how the binary is licensed. Accepting that license (even in places where software patents don't apply) could potentially cause issues. I haven't read the license for it yet, but most I've seen this sentiment expressed in several posts. There are H.264 patents in the MPEG-LA AVC patent pool current and issued in something like 46 countries. I haven't checked what percentage of the world's population the list covers, but I would be surprised if it weren't on the order of 95%. ( http://www.mpegla.com/main/programs/avc/Documents/avc-att1.pdf ) In the US, at least, accepting a patent license (even paying for one) doesn't preclude you from challenging the validity of a patent. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: OpenH264 in Fedora
On Mon, Nov 4, 2013 at 10:35 AM, Alberto Ruiz ar...@redhat.com wrote: Google gave up on that battle, Mozilla gave up on that battle, and somehow you expect that the Fedora community can somehow turn the tides? There are better ways to push for improvements in this effort (like the Daala codec). Google most certantly has not. ( http://www.ietf.org/mail-archive/web/rtcweb/current/msg09338.html ) Mozilla's position is In previous discussions of which codec should be MTI, Mozilla has stated that it could not accept H.264 as MTI, primarily because we could not deliver H.264 in Firefox. That obstacle is now removed, and we can accept either codec as MTI. ( http://www.ietf.org/mail-archive/web/rtcweb/current/msg09305.html ) As I outlined at the thread outset. The most obvious possible outcomes is one of: (0) H264 will be selected as mandatory to implement. (1) VP8 will be selected as mandatory to implement. (2) There will be no consensus for a mandatory to implement video codec. (and the market will do what it does but an implementation which was $not-h.264 only would not be non-conformant with the specification) The working group had a strong preference going in to have a MTI video codec (and achieved one for Audio) in order to maximize compatibility. This benefits is lost if parties will not implement a mandatory one even if its mandatory. Again, the people who have been fighting for open source media Xiph.org and the Mozilla organization have already acknowledge that while this situation is not ideal, is an improvement over the current situation, I'd say we should trust these guys a little when it comes to these things, don't you think? Certainly from anyone's personal perspective OpenH264 existing is abstractly better than it not existing. It's a hobson's choice: If it doesn't help you, don't use it. If it does, do. You can't lose. It exists now. Hurrah. I'm commenting here as a Fedora user of many years, but I am a Xiph developer for many more years (and one of the people working on Daala), and (as an aside, lest someone think I'm hiding it, a Mozilla employee). I believe if Fedora developers believe that this will allow Fedora to ship H.264 that y'all ought to go point it out to the working group. The working group can't consider what it doesn't know, and right now it has been aggressively claimed that that the OpenH264 will make H.264 available at no cost to practical everyone where it isn't already available. The question left is will making H.264 MTI be an decision that excludes free software. I believe that it is— and the comments on this list suggest other people agree with me. It's hard to make the argument however when Debian shipping h.264 in the default install and no one heavily involved with other distributions or working on other projects speaking up and saying otherwise. As is was the prior state was Google saying they wouldn't ship H.264 in WebRTC, Mozilla saying they _couldn't_, and a whole lot of loud legacy equipment vendors (whos stuff is not directly compatible with WebRTC regardless because of the mandatory DTLS+SRTP, etc) saying that they won't implement VP8. Since the OpenH264 announcement the new claim is that there are no substantial couldn'ts commenting on the list anymore. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: OpenH264 in Fedora
On Mon, Nov 4, 2013 at 11:03 AM, Bruno Wolff III br...@wolff.to wrote: I was thinking more of the non-commercial use restrictions you might end up agreeing to when you accept the license of the binary. In the places where software patents didn't apply, you'd probably either use x264 or build openh264 from source to avoid those restrictions. Non-commercial language is part of the MPEG-LA standard license, I believe it dates back to MPEG-2 or even before. AFAIK, no H.264 product is licensed for commercial use (whatever that means! the license doesn't define it)... including things like Final Cut Pro ( http://bemasc.net/wordpress/2010/02/02/no-you-cant-do-that-with-h264/ ). Personally I think its just one more of the horrible mess of codec licensing, it's just one of many ways to violate the complicated licenses for the licensor to extract more rent from you if its in their business interest to do so... But in this case the problem is not specific to OpenH264. (Though an unwillness to accept a non-commercial license compared to no license at all is an interesting argument. Though, considering that OpenH264 somewhat undermines (the least important part of) the revenue model here, it's not likely that anyone is going to get MPEG-LA to change their long standing license terms over complaints arising from that discussion. :) codecs process data provided provided by untrusted sources, for security reasons you don't want these bundled with apps. Codecs have generally had a long track record of security disasters. This is one of several reasons several major browsers either haven't used system codecs at all or only by white-listed exception... as many codecs that get installed on systems have never even been fuzz tested and, in the past, have been trivially exploitable. More application embedding for this stuff is probably not a great plan. A few major applications that have dedicated security teams can keep up with this stuff, but that doesn't apply generally to all applications. -- 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: OpenH264 in Fedora
On Mon, Nov 4, 2013 at 11:29 AM, Bruno Wolff III br...@wolff.to wrote: I have asked on the advisory-board list about getting an official Fedora position on OpenH264 before the vote occurs. I don't want to be making claims about Fedora on my own on how far Fedora will or won't go in supporting OpenH264. (This could in theory affect our ability to use the Firefox trademark if we block its ability to download that codec from Cisco. Assuming that the download is implemented in Firefox.) Thank you, thats exactly the sort of thing I wanted here. (In the IETF posters speak for themselves, with the limits of their own uncertainty, but it's better to be able to report on an actual decision where one is possible.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn denni...@conversis.de 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 obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. I think it's needed on the first day that wayland desktop applications are widely deployed— someone shouldn't have to choose between the wayland ui and network transparency. I suppose there is plenty of room to disagree
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 5:11 PM, Genes MailLists li...@sapience.com 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 cmad...@hiwaay.net 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 jrei...@bitwagon.com 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 a...@redhat.com 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 mschwe...@gmail.com 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 oget.fed...@gmail.com 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 gilb...@gmail.com 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: Trusted Boot in Fedora
On Fri, Jun 24, 2011 at 4:07 AM, Rahul Sundaram methe...@gmail.com 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 tm...@redhat.com: On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote: On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell gmaxw...@gmail.com 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: pidgin-otr security update pushed - please test and give karma
On Wed, May 16, 2012 at 10:16 AM, Paul Wouters pwout...@redhat.com 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 ja...@redhat.com 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 b...@redhat.com 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 pjo...@redhat.com wrote: You're wrong. Users will have the ability to create their own signing certificates with openssl and sign their own binaries. Using MS as a signer only buys you the convenience of not making everybody who wants to install your software enroll your key. But they will be able to do that if that's what you want. It's perhaps just as troubling that there are people involved in this non-public decision who apparently have such a limited understanding of free software that they were unable to understand the point I made explicitly in my message (and more elliptically in my subject). How can I trust that you really had no other alternative, when you can't even see the loss of freedom associated with this? One of the Infinite Freedoms Fedora has previously included is the infinite potential of creating forks— software that _other people_ will load— which are Fedora's technological equals and which themselves enjoy the same freedom as Fedora. A change from an uncountable infinity of options, to a merely countable infinity. Under this model there will be two classes of distributor: One which loads easily on systems, and one which requires the additional effort of disabling secure boot or installing user keys. (And ARM will be even more interesting...) You might argue that the cost of installing keys / disabling secure-boot is sufficiently low— but if if it really were, why bother with it for Fedora, why legitimize this kind of signed boot-loader only control by playing along with it. So perhaps in practice the loss of freedom is small— but at the same time people advocating closed software will rightly point out that very few users can program and fewer still care to actually do so. None the less, I do not believe it is FUD or in any way inaccurate to say that this will mean that Fedora will be losing a freedom it once had— the freedom to make forks at no cost which are technically equal to the projects, ones which are just as compatible and easy to 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 b...@redhat.com 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 pjo...@redhat.com 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
Re: *countable infinities only
On Thu, May 31, 2012 at 12:11 PM, Gerry Reno gr...@verizon.net 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č m...@volny.cz 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 basilgo...@librevideo.org 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 1:07 PM, Gerry Reno gr...@verizon.net 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 nott...@redhat.com 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 gr...@verizon.net 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 gr...@verizon.net 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 gr...@verizon.net 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 h.rei...@thelounge.net 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 d...@redhat.com 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 d...@redhat.com 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 s...@redhat.com 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 d...@redhat.com 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 m...@cchtml.com 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 h.rei...@thelounge.net 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 h.rei...@thelounge.net 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 cmad...@hiwaay.net 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 drag...@gmail.com 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 cmad...@hiwaay.net wrote: Once upon a time, Gregory Maxwell gmaxw...@gmail.com 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 jkeat...@j2solutions.net 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 h.rei...@thelounge.net 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 mj...@srcf.ucam.org 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 mj...@srcf.ucam.org 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 mj...@srcf.ucam.org 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 drag...@gmail.com wrote: On Sat, Jun 2, 2012 at 11:14 PM, Gregory Maxwell gmaxw...@gmail.com 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 mj...@srcf.ucam.org 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 gmaxw...@gmail.com wrote: On Sat, Jun 2, 2012 at 5:57 PM, Matthew Garrett mj...@srcf.ucam.org 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 drag...@gmail.com 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 pjo...@redhat.com 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 nicu_fed...@nicubunu.ro 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 pjo...@redhat.com 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 awill...@redhat.com 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 nott...@redhat.com 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 pjo...@redhat.com 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 pjo...@redhat.com 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 li...@colorremedies.com 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 li...@colorremedies.com 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 li...@colorremedies.com 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 h.rei...@thelounge.net 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 hughsi...@gmail.com 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 drag...@gmail.com 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 mzerq...@0pointer.de 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 jkeat...@j2solutions.net 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 li...@colorremedies.com 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 mzerq...@0pointer.de 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 awill...@redhat.com 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 e...@brouhaha.com 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
