spin development: how to trust an iso built outside the fedora build sys
Hi there, I was wondering if there is any process that we (spin developers - music list) could use to confirm that a spin iso was 1. built with a particular kickstart file (or list of files when there is kickstart %include x directives). 2. hasn't been doctored on purpose eg by the person building the iso, or corrupted by the upload/download process 3. hasn't been tainted by unknown code on the build machine A few thoughts: 1. the spin build process could place copies of all the spin kickstarts files in a folder on the destination machine eg /root/build-process. This would be in addition to the automatically created anaconda-ks.cfg (which is the combined ks file). 2. shaNsum created by the spin creator and uploaded alongside the iso 3. content test by downloader of the iso: - mount -o loop/image on existing known good system - using known system rpm -Va all packages - using known system tools, compare filelist from on image rpm db with complete list of files on disk to indicate every extra file present anywhere on the image. list the name and contents of them. - above check to indicate every modified rpm installed file 4. If a user builds a spin at a different time, or with repo out of sync, I expect that I could get different versions of packages in my build, so I don't think you could say: User built from the spin kickstart, and has a different sized/content iso, hence the original spin is faulty. Does that make sense ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mailing list guidelines and smartphones
At 21:08 on 14 Aug 2010, Jesse Keating wrote: Right, not very convenient at all. There is a bug open with K9, the email client I'm using, to allow for bottom posting, but given how it seem bottom posting is relegated to nerd lists anyway it may not happen. Sadly the vast majority of the world is stuck using outlook and default gmail/thunderbird produced top posting and those of us that care are in a constant battle against it. 1. Hit reply 2. Long-touch on the quoted text Copy all 3. Long-touch on the message text Paste 4. Touch the [X] above the quoted text to remove the original quoted message -- Mark Knoop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters
Hi, I have an ATI Mobility Radeon X300 based laptop (x86) and tried to boot the boot.iso by using livecd-iso-to-disk but the installer could not see the image (CD/DVD not present, other options NFS, local disk - not including the USB device, URL, etc) once the laptop booted from usb. It did not make it as far as X. Is it necessary to burn a DVD to try this test? I'm trying the live CD next but that wasn't part of the test. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100815 changes
Compose started at Sun Aug 15 08:15:08 UTC 2010 Broken deps for x86_64 -- Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libvala.so.0 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libvala.so.0()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) clusterssh-3.28-1.fc15.noarch requires xorg-x11-fonts\* cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mine_detector-6.0-3.fc13.x86_64 requires
Re: Mailing list guidelines and smartphones
On Sat, 14 Aug 2010 21:08:12 -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/14/2010 08:50 PM, inode0 wrote: On Saturday, August 14, 2010, Jesse Keating jkeat...@redhat.com wrote: I'm still looking for an android email client that allows me to place the reply below the quoted text. I guess an alternative is to delete the entire quoted text... While not very convenient the web browser let's you do whatever you please. John Right, not very convenient at all. There is a bug open with K9, the email client I'm using, to allow for bottom posting, but given how it Actually you can do it now. Just touch inside the Quoted text window then you can move the cursor around, delete text, place your text where you want etc. Andrew -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upcoming Fedora 14 Linux Release
Dear All, May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? Thank you very much. Yours sincerely, Mr. Teo En Ming (Zhang Enming) Citizenship: Singapore Citizen/Singaporean Facebook account:http://www.facebook.com/profile.php?id=10750083982 Location: Bedok Reservoir Road, Singapore 470103 My Open Letter (Plea for Medical Help/Assistance) to World Leaders: http://lists.fedoraproject.org/pipermail/users/2010-August/380213.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100815 changes
Compose started at Sun Aug 15 13:15:29 UTC 2010 Broken deps for x86_64 -- CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 avogadro-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) avogadro-libs-1.0.1-2.fc14.i686 requires libboost_python-mt.so.1.41.0 avogadro-libs-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) bastet-0.43-7.fc13.x86_64 requires libboost_program_options.so.1.41.0()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) easystroke-0.5.3-1.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fuse-encfs-1.5-12.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.i686 requires libboost_serialization-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fuse-encfs-1.5-12.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit)
Re: Mailing list guidelines and smartphones
On Sun, Aug 15, 2010 at 6:05 AM, Andrew Clayton and...@digital-domain.net wrote: On Sat, 14 Aug 2010 21:08:12 -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/14/2010 08:50 PM, inode0 wrote: On Saturday, August 14, 2010, Jesse Keating jkeat...@redhat.com wrote: I'm still looking for an android email client that allows me to place the reply below the quoted text. I guess an alternative is to delete the entire quoted text... While not very convenient the web browser let's you do whatever you please. John Right, not very convenient at all. There is a bug open with K9, the email client I'm using, to allow for bottom posting, but given how it Actually you can do it now. Just touch inside the Quoted text window then you can move the cursor around, delete text, place your text where you want etc. Andrew -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I think that feature is only in Android 2.2 devices because that function is not available on my Droid X running Android 2.1 but I believe I had that on my Droid running CyanogenMod6. -AdamM -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
On Sat, Aug 14, 2010 at 08:25:46PM -0700, Matt McCutchen wrote: I am aware of that. But FESCo has the authority to override the maintainer, and in their recent discussion of the SELinux patch, they decided not to move forward on the basis of the trademarks: https://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html#l-66 Maybe the maintenance burden alone would also be enough to block further consideration of the patch, but there is no way to tell that from their discussion. We have the authority to do that, and the decision you're referring to effectively *did* override the maintainer by saying that the selinux policy change should be reverted. If a package is generally well-maintained and then broken by a change introduced by another maintainer, there has to be a very strong argument to do anything other than revert the change that broke things in the first place. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
Matthew Garrett wrote: We have the authority to do that, and the decision you're referring to effectively *did* override the maintainer by saying that the selinux policy change should be reverted. If a package is generally well-maintained and then broken by a change introduced by another maintainer, there has to be a very strong argument to do anything other than revert the change that broke things in the first place. But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. JavaScript JITs should be banned. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin development: how to trust an iso built outside the fedora build sys
On Sun, Aug 15, 2010 at 19:02:36 +1000, David Timms dti...@iinet.net.au wrote: I was wondering if there is any process that we (spin developers - music list) could use to confirm that a spin iso was 1. built with a particular kickstart file (or list of files when there is kickstart %include x directives). 2. hasn't been doctored on purpose eg by the person building the iso, or corrupted by the upload/download process 3. hasn't been tainted by unknown code on the build machine My first suggestion is to build the iso yourself. A few thoughts: 1. the spin build process could place copies of all the spin kickstarts files in a folder on the destination machine eg /root/build-process. This would be in addition to the automatically created anaconda-ks.cfg (which is the combined ks file). A fake spin could put the files you expect there, but not really use them. 2. shaNsum created by the spin creator and uploaded alongside the iso That is reasonable if you both create and distribute isos. 3. content test by downloader of the iso: - mount -o loop/image on existing known good system - using known system rpm -Va all packages Weeding out false positives here would make this step pretty tricky. - using known system tools, compare filelist from on image rpm db with complete list of files on disk to indicate every extra file present anywhere on the image. list the name and contents of them. - above check to indicate every modified rpm installed file 4. If a user builds a spin at a different time, or with repo out of sync, I expect that I could get different versions of packages in my build, so I don't think you could say: User built from the spin kickstart, and has a different sized/content iso, hence the original spin is faulty. Does that make sense ? I don't think you get bit identical spins if you build at different times, and you certainly don't if there are different versions of packages being used. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Javascript JIT in web browsers
On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
On Sun, 15 Aug 2010 22:07:47 +0800 Mr. Teo En Ming (Zhang Enming) of Singapore space.time.unive...@gmail.com wrote: Dear All, May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? Thank you very much. No, I don't think so. There is an experemental dom0 kernel available however from: http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ There's a feature: http://fedoraproject.org/wiki/Features/XenPvopsDom0 which is NOT in f14. You may want to mail myo...@fedoraproject.org directly for more details. kevin signature.asc Description: PGP signature -- 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 9:45 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. The times where javascript is only used for some fancy effects are long over ... welcome to 2010 ;) An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. The problem is fixable there is a patch that is being discussed upstream to fix the issue and allow selinux memory protection it is just not merged yet. Using a JIT is not a security risk by itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote: On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. The problem is fixable there is a patch that is being discussed upstream to fix the issue and allow selinux memory protection it is just not merged yet. I'm not holding my breath. The patch would avoid one particularly risky behavior, but the browser still has a very large attack surface. OS-level sandboxing is a good idea in any case. -- Matt -- 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 10:49 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote: On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. The problem is fixable there is a patch that is being discussed upstream to fix the issue and allow selinux memory protection it is just not merged yet. I'm not holding my breath. The patch would avoid one particularly risky behavior, but the browser still has a very large attack surface. OS-level sandboxing is a good idea in any case. True, but this is not specific to javascript (jit) but the browser itself is the number one attack vector on desktop systems, so yeah sandboxing should indeed help. But calls like javascript JITs should be banned are just nonsense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
On Sun, 15 Aug 2010, Mr. Teo En Ming (Zhang Enming) of Singapore wrote: May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? No. The Fedora policy isn't to include dom0 support until it makes it into the upstream kernel. Some pieces have made it into 2.6.36 pre-rc but more are required before dom0 will work. It might be in f15 if 2.6.37 is out in time and if dom0 support is in it, though f16 or later is more likely. Note that in the f14 and rawhide xen package xm and possibly xend are currently broken due to python 2.6-2.7 changes in xmlrpc. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
drago01 wrote: The times where javascript is only used for some fancy effects are long over ... welcome to 2010 ;) Some web sites are indeed abusing JavaScript. Why should we promote this behavior? It is a vehicle for proprietary software, where people often aren't even aware they're using non-Free code, or just ignore the issue. See also http://www.gnu.org/philosophy/javascript-trap.html . A web site is not and should not be an application, an application is not and should not be a web site. The problem is fixable there is a patch that is being discussed upstream to fix the issue and allow selinux memory protection it is just not merged yet. Using a JIT is not a security risk by itself. Workarounds which make SELinux happy are still not as secure as sticking to a pure bytecode interpreter. Exploit code can still write to the memory to be executed, with ANY JIT, as this is how a JIT works. It's just that the writing has to happen through a different address space window as the execution, making the JIT harder, but not impossible, to exploit. So IMHO the right fix is to disable the JIT altogether. But the proposed patch would still be better than the crappy solution implemented now just to stick to upstream (having SELinux ignore the problem). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
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. It is a vehicle for proprietary software, where people often aren't even aware they're using non-Free code, or just ignore the issue. See also http://www.gnu.org/philosophy/javascript-trap.html . If you use a non-free web site, you have already lost the freedom to read, distribute, and modify the code you are relying on (http://www.gnu.org/philosophy/who-does-that-server-really-serve.html). I fail to see how running the site's non-free JavaScript for the sole purpose of interacting with that site makes the situation any worse. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Matt McCutchen wrote: If you use a non-free web site, you have already lost the freedom to read, distribute, and modify the code you are relying on (http://www.gnu.org/philosophy/who-does-that-server-really-serve.html). I fail to see how running the site's non-free JavaScript for the sole purpose of interacting with that site makes the situation any worse. The JavaScript is indeed only part of the problem, the server-side code is the other half. But both are non-Free, and therefore both and thus the web app as a whole should not be used. Kevin Kofler -- 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 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. -- 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: New bodhi release in production
On Sat, Aug 14, 2010 at 13:09, List Troll mrlisttr...@gmail.com wrote: On Sat, Aug 14, 2010 at 8:05 PM, Kevin Kofler kevin.kof...@chello.at wrote: Martin Sourada wrote: I still remember the epic fail of having KDE 4.0 in stable fedora * I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all the showstoppers before F9 was released, and were also quick to ship updates fixing more annoyances, including updates to later 4.0.x releases. Yes, I used F9 with 4.0.x myself, one one machine. Wow, you actually used F9 yourself (on one machine)? What an accomplishment. Stop. This is neither useful, being excellent or anything else beyond throwing ape-cakes to see who else gets caught up in it. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
Dear M A Young, Thank you for your prompt reply and updates. I will stick to Fedora 11 at the moment until Fedora 16 or later. Thank you very much. Yours sincerely, Mr. Teo En Ming (Zhang Enming) Citizenship: Singapore Citizen/Singaporean Facebook account:http://www.facebook.com/profile.php?id=10750083982 Location: Bedok Reservoir Road, Singapore 470103 My Open Letter (Plea for Medical Help/Assistance) to World Leaders: http://lists.fedoraproject.org/pipermail/users/2010-August/380213.html On 08/16/2010 05:14 AM, M A Young wrote: On Sun, 15 Aug 2010, Mr. Teo En Ming (Zhang Enming) of Singapore wrote: May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? No. The Fedora policy isn't to include dom0 support until it makes it into the upstream kernel. Some pieces have made it into 2.6.36 pre-rc but more are required before dom0 will work. It might be in f15 if 2.6.37 is out in time and if dom0 support is in it, though f16 or later is more likely. Note that in the f14 and rawhide xen package xm and possibly xend are currently broken due to python 2.6-2.7 changes in xmlrpc. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
Dear Kevin Fenzi, Michael Young has already replied. Thank you very much. Yours sincerely, Mr. Teo En Ming (Zhang Enming) Citizenship: Singapore Citizen/Singaporean Facebook account:http://www.facebook.com/profile.php?id=10750083982 Location: Bedok Reservoir Road, Singapore 470103 My Open Letter (Plea for Medical Help/Assistance) to World Leaders: http://lists.fedoraproject.org/pipermail/users/2010-August/380213.html On 08/16/2010 04:29 AM, Kevin Fenzi wrote: On Sun, 15 Aug 2010 22:07:47 +0800 Mr. Teo En Ming (Zhang Enming) of Singapore space.time.unive...@gmail.com wrote: Dear All, May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? Thank you very much. No, I don't think so. There is an experemental dom0 kernel available however from: http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ There's a feature: http://fedoraproject.org/wiki/Features/XenPvopsDom0 which is NOT in f14. You may want to mail myo...@fedoraproject.org directly for more details. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
Mr. Teo En Ming (Zhang Enming) of Singapore wrote: I will stick to Fedora 11 at the moment until Fedora 16 or later. Uh, Fedora 11 is not supported anymore and it also never had a Xen Dom0 kernel, pvops or otherwise. The last Fedora release to ship a Xen Dom0 kernel was Fedora 8, and that was from the old Xen codebase which was rejected upstream. The Fedora kernel team stopped shipping the classic Xen at that point because they didn't want to spend their time porting non- upstream patchsets to the current upstream kernel (and in fact F8's kernel- xen lagged significantly behind the main kernel). Xen pvops DomU support was ready for F9, but Dom0 support is taking its time to get upstreamed (and the Fedora kernel team does not want to use non-upstream patchsets for the same reasons they stopped shipping classic Xen). So I'd suggest to use a currently supported Fedora release (12 or 13) with the unofficial Dom0 kernel RPMs out there (built for F12, I don't know if they work on F13). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
Dear Kevin Kofler, You may wish to check out my Youtube videos at http://www.youtube.com/user/enmingteo for my Xen pv-ops Dom0 kernels and also VGA passthrough which were implemented in my Fedora 11 x86_64 home multimedia desktop tower system (at the time of this writing, there are 20 uploaded videos in my Youtube account). You may also wish to read my open letter for details on how I managed to get Xen pv-ops dom0 kernels installed into Fedora 11 (extremely technical). You will have to dig through my postings at the Xen-devel mailing list from July 2009 to November 2009. Please click the following internet link for my open letter. http://lists.mcs.anl.gov/pipermail/mpich-discuss/2010-August/007693.html Yours sincerely, Mr. Teo En Ming (Zhang Enming) Citizenship: Singapore Citizen/Singaporean Facebook account:http://www.facebook.com/profile.php?id=10750083982 Location: Bedok Reservoir Road, Singapore 470103 My Open Letter (Plea for Medical Help/Assistance) to World Leaders: http://lists.fedoraproject.org/pipermail/users/2010-August/380213.html On 08/16/2010 11:43 AM, Kevin Kofler wrote: Mr. Teo En Ming (Zhang Enming) of Singapore wrote: I will stick to Fedora 11 at the moment until Fedora 16 or later. Uh, Fedora 11 is not supported anymore and it also never had a Xen Dom0 kernel, pvops or otherwise. The last Fedora release to ship a Xen Dom0 kernel was Fedora 8, and that was from the old Xen codebase which was rejected upstream. The Fedora kernel team stopped shipping the classic Xen at that point because they didn't want to spend their time porting non- upstream patchsets to the current upstream kernel (and in fact F8's kernel- xen lagged significantly behind the main kernel). Xen pvops DomU support was ready for F9, but Dom0 support is taking its time to get upstreamed (and the Fedora kernel team does not want to use non-upstream patchsets for the same reasons they stopped shipping classic Xen). So I'd suggest to use a currently supported Fedora release (12 or 13) with the unofficial Dom0 kernel RPMs out there (built for F12, I don't know if they work on F13). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Config-Model
perl-Config-Model has broken dependencies in the rawhide tree: On x86_64: perl-Config-Model-1.205-3.fc15.noarch requires perl(YAML::Any) = 0:0.303 On i386: perl-Config-Model-1.205-3.fc15.noarch requires perl(YAML::Any) = 0:0.303 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Config-Model
perl-Config-Model has broken dependencies in the F-14 tree: On x86_64: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 On i386: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 620423] perl-Perl-Critic - Request for EL-6 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=620423 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Perl-Critic-1.105-2.el ||6 Resolution||NEXTRELEASE Last Closed||2010-08-15 14:25:32 --- Comment #3 from Paul Howarth p...@city-fan.org 2010-08-15 14:25:32 EDT --- Branched and built: http://koji.fedoraproject.org/koji/buildinfo?buildID=190251 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 624308] New: Package pre-dates the discovery of fire.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Package pre-dates the discovery of fire. https://bugzilla.redhat.com/show_bug.cgi?id=624308 Summary: Package pre-dates the discovery of fire. Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: high Priority: low Component: perl-DBIx-Class-Schema-Loader AssignedTo: cw...@alumni.drew.edu ReportedBy: da...@fetter.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Description of problem: There's a terribly ancient version of the software packaged for F13 Version-Release number of selected component (if applicable): 0.04006 How reproducible: Steps to Reproduce: 1. perl -MDBIx::Class::Schema::Loader -le 'print $DBIx::Class::Schema::Loader::VERSION' Actual results: 0.04006 Expected results: 0.07001 Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Xhtml] Update to 1.61
commit 99b906994e120a86be42cd9f89dcbfc30688db6d
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Mon Aug 16 02:42:10 2010 +0200
Update to 1.61
perl-Pod-Xhtml.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Pod-Xhtml.spec b/perl-Pod-Xhtml.spec
index b0de77c..13f2360 100644
--- a/perl-Pod-Xhtml.spec
+++ b/perl-Pod-Xhtml.spec
@@ -1,5 +1,5 @@
Name: perl-Pod-Xhtml
-Version:1.60
+Version:1.61
Release:1%{?dist}
Summary:Generate well-formed XHTML documents from POD format
documentation
License:GPLv2+
@@ -16,7 +16,7 @@ BuildRequires: perl(URI::Escape)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module parses files containing POD content and genrates well-formed
+This module parses files containing POD content and generates well-formed
XHTML documents from it.
%prep
@@ -51,6 +51,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Aug 16 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 1.61-1
+- Update to 1.61
+- fix description
+
* Sun Aug 01 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 1.60-1
- Update to 1.60
- Re-enable tests
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Pod-Xhtml-1.61.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Pod-Xhtml: 51e17843d0c91592ed10d21dec5ed60f Pod-Xhtml-1.61.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Xhtml] Update to 1.61
commit dc0471e226f1f9cc279abfb3cb29854685bc70d5 Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr Date: Mon Aug 16 02:42:50 2010 +0200 Update to 1.61 .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index a843652..4096379 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ Pod-Xhtml-1.59.tar.gz Pod-Xhtml-1.60.tar.gz +Pod-Xhtml-1.61.tar.gz diff --git a/sources b/sources index 58305ee..2e939d1 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -291d852a211902dce316a32b3e2c5ca8 Pod-Xhtml-1.60.tar.gz +51e17843d0c91592ed10d21dec5ed60f Pod-Xhtml-1.61.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 624308] Package pre-dates the discovery of fire.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=624308 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com AssignedTo|cw...@alumni.drew.edu |iarn...@gmail.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 624308] Package pre-dates the discovery of fire.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=624308 --- Comment #3 from Iain Arnell iarn...@gmail.com 2010-08-16 01:37:53 EDT --- I should have all the deps ready for review within the next couple of days. The bottom level has another 7 missing packages in addition to Lingua::PT::Stemmer; at least that seems to be the bottom of the chain, though. Even if everything passes review quickly (are you able to handle some of them?), I guess it could take around 5-6 weeks for everything to work its way through updates-testing into F13/F14. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
