Re: Passing ownership of mingetty
On Wed, Nov 10, 2010 at 09:33:26PM -0500, Bernie Innocenti wrote: I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package. Since you're clearly working on it, I think it would make sense to pass ownership to you. If you agree, I will orphan the package so you can take it over (there doesn't seem a way to do a direct transfer in pkgdb). Ok. Just orphan mingetty and ping me. I will take it in turn. -- Petr pgpgOP6T4h4Ue.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SWI Prolog is gone from F13 and F14
Acctually gemi still owns the package. He's on turn now. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101111 changes
Compose started at Thu Nov 11 08:15:03 UTC 2010 Broken deps for x86_64 -- apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) claws-mail-plugins-notification-3.7.6-7.fc15.x86_64 requires libnotify.so.1()(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()(64bit) dh-make-0.55-2.fc15.noarch requires debhelper edje-0.9.99.49898-1.fc14.i686 requires libecore_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libembryo-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libevas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libembryo-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) edje-devel-0.9.99.49898-1.fc14.i686 requires pkgconfig(eina-0) edje-devel-0.9.99.49898-1.fc14.x86_64 requires pkgconfig(eina-0) eekboard-0.0.5-3.fc15.x86_64 requires libnotify.so.1()(64bit) efreet-0.5.0.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) efreet-devel-0.5.0.49898-1.fc14.i686 requires pkgconfig(eina-0) efreet-devel-0.5.0.49898-1.fc14.x86_64 requires pkgconfig(eina-0) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeconnman-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libehal-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libedbus-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libebluez-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeofono-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_x-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_con-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_ipc-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit)
Orphaning gedit-vala
Hi all, I'm orphaning gedit-vala (upstream name: vtg); a plugin for doing Vala development in gedit. It's in good shape on F-14, waiting for upstream fixes for Rawhide (since we're shipping gedit 2.9x.y there) and there are some problems on F-12 and F-13 that would need the Vala stack to be updated to fix (we might do that, I'll poll the interested Vala parties on a separate thread). If anyone's interested, please claim the package. I'll still be co- maintaining for a while to make sure the package is still receiving some care. https://admin.fedoraproject.org/pkgdb/acls/name/gedit-vala I'll still be maintaining the underlying Vala stack. Thanks, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () 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: RPM: signing uncompressed data instead of signed data?
On Thu, Nov 11, 2010 at 10:41:13 +, Andre Robatino robat...@fedoraproject.org wrote: The question was raised why RPMs sign their compressed data, rather than uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to changes in compression such as the recent one in xz.) The answer had to do with the fact that higher-level tools (createrepo and yum) depend on the current behavior, but that doesn't address whether it's just an early design mistake that we're locked into now, or if there's actually some overall advantage to doing things this way (that outweighs the obvious disadvantage of inflexibility in how the data is compressed). Can anyone shed some light on this? Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does my mail client/web browser not appear in GNOME?
On Wed, 2010-11-10 at 12:14 -0800, Adam Williamson wrote: On Wed, 2010-11-10 at 19:21 +, Bastien Nocera wrote: Or why is my dingus click not working? Your web browsers and mail clients need to handle x-scheme-handler/http[1] and x-scheme-handler/mailto respectively to be listed in the GNOME default applications in the new control-center. Once our default applications are setup, I'll make the necessary changes in shared-mime-info for the applications to be picked up. See: http://www.hadess.net/2010/10/new-control-center-and-you.html and http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#id2869854 for details. [1]: And probably x-scheme-handler/https on the topic of the new control-center, any chance of making it work at all any time soon? :) http://bugzilla.redhat.com/show_bug.cgi?id=651510 2.91.2 was built 2 days ago. Though it might not be installable because we need a new gnome-media, and get libgnome-media-profiles into rawhide. Reviews welcome: https://bugzilla.redhat.com/show_bug.cgi?id=651863 Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RPM: signing uncompressed data instead of signed data?
Bruno Wolff III wrote: Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. I was thinking that since the signature check usually passes, the data could be uncompressed into a cache, checked there, then copied into place (assuming the check passes). If the data is capable of escaping from that sandbox before being checked, that's a serious security bug in the compression software that should be fixed in any case. (Sorry for not responding in-thread. Gmane isn't updating its list of existing threads.) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, 2010-11-11 at 10:41 +, Andre Robatino wrote: I came across the following old post, which I'm not responding to in-thread due to its age. https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517.html The question was raised why RPMs sign their compressed data, rather than uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to changes in compression such as the recent one in xz.) That's not true, there are four checks for delta rpms: 1. yum-presto runs checksums on the installed rpm, and the downloaded deltarpm. If these pass it then creates a new .rpm from those two sources. 2. Yum then checks that any rpm it has on disk matches the checksum it has from the repodata. 3. Yum then asks rpm to check the gpg signature of the new rpm. 4. Yum then looks at the SHA1HEADER for the rpm (which, again, is over the compressed contents). ...now it's possible that #3 will change within the next year or so, but it is much more likely to end up simpler than more complicated (Eg. detached signature of the entire file). IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg. http://james.fedorapeople.org/python/delta-rpm-dir.py -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.29 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, Nov 11, 2010 at 09:29:54 -0500, Andre Robatino robat...@fedoraproject.org wrote: Bruno Wolff III wrote: Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. I was thinking that since the signature check usually passes, the data could be uncompressed into a cache, checked there, then copied into place (assuming the check passes). If the data is capable of escaping from that sandbox before being checked, that's a serious security bug in the compression software that should be fixed in any case. The issue is the uncompression itself rather than the resulting uncompressed data being used. It is easy to do a DOS by compressing a very large file of constant data and having the victum fill up their disk. Also compression / decompression seems to be an area where proper paranoia isn't practiced and malformed data can cause problems. There have been several cases of libraries handling compressed image formats allowing arbitrary execution of code when operating on trojan images. I suspect that historically the people writing this kind of code were more interested in speed than security. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RPM: signing uncompressed data instead of signed data?
James Antill wrote: IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg. http://james.fedorapeople.org/python/delta-rpm-dir.py I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently, but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used, and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now? (Again, sorry for not replying in-thread, but Gmane isn't updating.) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, Nov 11, 2010 at 10:17:57AM -0500, Andre Robatino wrote:
I realize there's a lot of stuff sitting on top of RPM that depends on
how it works currently, but in terms of correctness, it still seems to
me to make more sense to sign the uncompressed data, since that's what
actually gets used, and it would avoid issues like
https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
with periodically as long as compression continues to improve. So let me
rephrase the question: in an alternate universe where RPM was originally
designed to sign the uncompressed data, and the higher-level tools were
subsequently designed to work with that, is there any fundamental reason
why things would be worse (or better) than they are now?
Securitywise ist would be a bit worse, because the decompression
libraries may contain exploitable bugs, so checking the
signature of a rpm might be already a dangerous operation.
(But most repositories nowadays already contain checksums over
the complete rpm, and most people trust repositories, not
individual rpms.)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On 11/11/2010 07:17 AM, Andre Robatino wrote: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now? The bytes that are signed would be farther away from the contents of the .rpm file. The compression would occur in between the signing and packing the file, so the signing would be less end-to-end with respect to packing the contents into the file. This changes the data integrity implications of signature that does not match. Some uses want more protection against mere transmission errors of the file, other uses want more independence of the various steps in a larger process (ability to change compression without changing signature, for example.) -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SWI Prolog is gone from F13 and F14
On Tue, 09 Nov 2010 18:14:42 +, Joel wrote: Is anyone interested in resurrecting SWI Prolog? I just noticed that it was dropped from F13 and F14. The version in F12 was 5.7.11, the current version is 5.10.2 according to: http://www.swi-prolog.org/ The previous packager was Gerard Milmeister. Gérard has not been heard of in quite a while; I've just started a non- responsive process on him a few days ago: https://bugzilla.redhat.com/show_bug.cgi?id=612094 Those of us who are maintaining his packages in the meantime should probably try to contact him too. We might need a mass-orphaning if Gérard cannot continue his Fedora work anymore. Regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () 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: RPM: signing uncompressed data instead of signed data?
On Thu, 2010-11-11 at 10:17 -0500, Andre Robatino wrote: James Antill wrote: IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg. http://james.fedorapeople.org/python/delta-rpm-dir.py I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently Maybe I wasn't clear ... the above code doesn't depend on rpm it depends on the bits being identical, as it's used to speed up mirroring Fedora (so the bits have to be identical for the mirror users). , but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used used is a loaded word here, as others have said from the point of view of different parts of yum/rpm it's the downloaded bits that are used and the uncompressed bits that are output. , and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now? So assuming we could magically change everything, what would we need to do stop any differences in compression from causing problems? In theory we could publish everything as uncompressed ... and then use http content-encoding to add xz/etc. compression back. But that'd break everything that's non-http ... and any http clients that don't do content-encoding (and AFAIK no client/server currently supports xz in content-encoding). The other option is for someone to add compat. code into xz, so we can say things like compress how you would have with version x.y.z. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer - Chris Ricker
On Nov 10, 2010, at 5:54 AM, Jaroslav Skarvada wrote: Hi, I was unsuccessful in all attempts to contact Chris Ricker (kaboom AT oobleck.net). He seems non-responsive for a long time, I did not receive any reply from him at least from February. Tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=554334 Previous attempt to contact through devel: http://lists.fedoraproject.org/pipermail/devel/2010-November/144873.html Personally I am interested in rrdtool (and I can take it), but there are also more packages with unresolved bugs I have to second someone taking over rrdtool. I handed it off to Chris a while back, but have still done far more work on it since then than he has, and I've not seen him touch an rrdtool bz in ages. :( (And no, I don't want maintainership back.) -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning gedit-vala
On Thu, Nov 11, 2010 at 7:19 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: Hi all, I'm orphaning gedit-vala (upstream name: vtg); a plugin for doing Vala development in gedit. It's in good shape on F-14, waiting for upstream fixes for Rawhide (since we're shipping gedit 2.9x.y there) and there are some problems on F-12 and F-13 that would need the Vala stack to be updated to fix (we might do that, I'll poll the interested Vala parties on a separate thread). If anyone's interested, please claim the package. I'll still be co- maintaining for a while to make sure the package is still receiving some care. https://admin.fedoraproject.org/pkgdb/acls/name/gedit-vala I'll still be maintaining the underlying Vala stack. Thanks, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () 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 I'll take it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Wed, 10.11.10 21:33, Bernie Innocenti (ber...@codewiz.org) wrote: Hello Petr, I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package. Do we really want to keep mingetty around? We discussed this a couple of times in the systemd context with people form various distros. In the interest of standardizing things across distros we would like to get all distros use the same getty implementation. Now, as it turns out contrary to what the name suggests mingetty actually uses a little bit more runtime memory than agetty, even though mingetty takes up a handful of bytes less disk space. (That said, the difference in memory and disk space is tiny enough to don't matter the tiniest bit on modern machines) Now, agetty is actively maintained inside u-l-ng, and used by most distros, except Fedora and Suse. Since u-l-ng is a core part of every Linux system and the mingetty pkg definitely not we started to work on making everybody use agetty and drop mingetty from the standard install everywhere. That way most distros would only have to install one getty implementation, and can use it for both serial consoles and VCs. Also it would use less disk space (since one getty binary takes less space than two, even if the one we keep is sligtly larger then the other one we remove), and less runtime memory. systemd git now ships with a default config which makes use of agetty, not mingetty -- on all distros. You apparently see value in keeping two almost identical getty implementations around. Can you elaborate why? Is there any feature missing in agetty that mingetty has? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
still a 2TB limit in F14 Anaconda, for LVM PV size
I just tried to install F14 on a new server with a 7.6 TB RAID (five Hitachi 2 TB drives on a 3ware 9750). I was pleased to see that the disk partitioning interface in Anaconda recognized the array and didn't have a problem with the size, reporting it as 7629352 MB. Unfortunately it won't let me create an LVM PV larger than 2 TB (2095151 MB). And if I try to create two PVs, it limits them to 1 TB each. Is there any good reason to have this limit, or should I report it as a bug against Anaconda (or some other component)? Thanks, Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On 11/08/2010 03:12 PM, Gregory Maxwell wrote: 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. Only if the laptop is configured to boot from the USB. But I know, everything here is theoretical. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Thu, Nov 11, 2010 at 08:53:47PM +0100, Lennart Poettering wrote: On Wed, 10.11.10 21:33, Bernie Innocenti (ber...@codewiz.org) wrote: Hello Petr, I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package. Do we really want to keep mingetty around? Your argument is sound, but this is still a bit off topic for this thread. Even if mingetty is retired it still needs a maintainer for another year until we retire F14 (unless we want to take a risk and try to swap it out in the public releases). I assume OLPC would have a similar issue. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still a 2TB limit in F14 Anaconda, for LVM PV size
On Thu, Nov 11, 2010 at 11:54:54AM -0800, Eric Smith wrote: I just tried to install F14 on a new server with a 7.6 TB RAID (five Hitachi 2 TB drives on a 3ware 9750). I was pleased to see that the disk partitioning interface in Anaconda recognized the array and didn't have a problem with the size, reporting it as 7629352 MB. Unfortunately it won't let me create an LVM PV larger than 2 TB (2095151 MB). And if I try to create two PVs, it limits them to 1 TB each. Is there any good reason to have this limit, or should I report it as a bug against Anaconda (or some other component)? I'm assuming this is because of MBR, and yes, it's a bug that really really needs to be fixed because you can now buy at retail cheap disks which are 2TB and larger. I think this is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=574551 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still a 2TB limit in F14 Anaconda, for LVM PV size
Eric Smith wrote: Is there any good reason to have this limit, or should I report it as a bug against Anaconda (or some other component)? Must be a new thing. I installed Fedora 11 on a server with an 8TB raid and it created a PV 2TB on its own. # pvscan PV /dev/sda2 VG VolGroup00 lvm2 [1.95 TiB / 64.00 MiB free] PV /dev/sdb1 VG VolGroup00 lvm2 [6.23 TiB / 0free] Total: 2 [8.19 TiB] / in use: 2 [8.19 TiB] / in no VG: 0 [0 ] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
I am not a kernel developer, but I do think it would be a step forward simply to erase a [substantial|critical] part of the physical memory before the system enters stages S4 or S5. An option in ACPI driver, implemented somewhere in acpi_os_stall() ?, I really don't know. Vaclav M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On 11/11/2010 07:55 PM, Roman Rakus wrote: On 11/08/2010 03:12 PM, Gregory Maxwell wrote: 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. Only if the laptop is configured to boot from the USB. But I know, everything here is theoretical. RR Yes, it's theoretical; I only wanted to know if there is a protection of any kind already implemented. I did a test and if i use an electric screwdriver I can get access to the laptop memory in eight seconds. The next step would be a freezer spray, -50C and less, removing of DIMMs from the laptop and reading them. I don't know how you, but when I am about to leave my workplace, I click on the button Shut Down and bye, bye, my computer, walking out of the room. Vaclav M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On 11/08/2010 10:18 AM, Petr Pisar wrote: So, after quick reading, this is not what I expected. This is just another kernel block cypher used by dmcrypt to (de)crypt block device data guartneeing encryption key does no leave CPU by storing the key in SSE register. The drawback is nobody can use SSE instructions then. -- Petr Yes, I went quickly through that theses and it is as you wrote - nobody can use streaming instruction any more. Similar approach might be a way for architectures, where is possible to allocate a part of the internal cache as a fast memory and place there what ever you want. Vaclav M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
- Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le samedi 06 novembre 2010 à 10:57 +, Richard W.M. Jones a écrit : Is Fedora for developers or what? We want to ditch extremely useful, ground-breaking features because of tearing when scrolling in a browser window? Well it would be mightily nice to have an infrastructure that can handle keyboard extended keys (almost every new keyboard sold in the last decade has one or more of those) without barfing because the original x11 protocol designers thought 8 bits would be enough for everyone. The ground breaking parts can come afterwards. Input on X is so bad this is becoming ridiculous (another example being X has no notion of language, just layouts, so there's no way for apps to know the language being typed and auto-select the correct spellchecker) Well, actually input methods can do that. :-) They know exactly what language you are typing, and some do basic spelling check in the language they support. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Register now for Red Hat Virtual Experience, December 9. Enterprise Linux, virtualization, cloud, and more. http://www.redhat.com/virtualexperience -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
It would be usefull to overwrite some parts of memory (keys etc.), before the computer is switched off. So, my question is: Is there already implemented and used some kind of protection? Boot Memory test from install media (DVD, LiveCD, LiveUSB, etc.) and let it run for a minute. Or, install memtest86+, boot that using GRUB, and run for a minute. Or, boot your own kernel that writes 0xFF, 0xa5, 0x5a, 0x00 successively to each byte, taking care to not get screwed by the data cache. Takes 10 seconds. Or, plan ahead, then just wait. Not worth the wait? Not worth much! -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does my mail client/web browser not appear in GNOME?
On Thu, 2010-11-11 at 14:21 +, Bastien Nocera wrote: on the topic of the new control-center, any chance of making it work at all any time soon? :) http://bugzilla.redhat.com/show_bug.cgi?id=651510 2.91.2 was built 2 days ago. Though it might not be installable because we need a new gnome-media, and get libgnome-media-profiles into rawhide. Reviews welcome: https://bugzilla.redhat.com/show_bug.cgi?id=651863 Looks like it's been taken care of. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still a 2TB limit in F14 Anaconda, for LVM PV size
Hi, 2010-11-11 20:54 keltezéssel, Eric Smith írta: I just tried to install F14 on a new server with a 7.6 TB RAID (five Hitachi 2 TB drives on a 3ware 9750). I was pleased to see that the disk partitioning interface in Anaconda recognized the array and didn't have a problem with the size, reporting it as 7629352 MB. Unfortunately it won't let me create an LVM PV larger than 2 TB (2095151 MB). And if I try to create two PVs, it limits them to 1 TB each. Is there any good reason to have this limit, or should I report it as a bug against Anaconda (or some other component)? Thanks, Eric I run into the same problem with installing F14 but fortunately it's easily solvable. I have split my 3.6TB RAID10 array into a 150GB boot volume plus the rest. I wanted to put /home to the 3.45TB volume but anaconda wanted to create an MSDOS partition by default. The 150GB volume is bootable from the BIOS, no problem, /boot, / and swap was put there. I had to press Ctrl-Alt-F2 and used parted on the console to create the GPT disklabel on the large volume and created one partition covering it all. Then used anaconda to accept the already existing partitions and used the large partition for /home. Ext4 had no problems formatting it. Best regards, Zoltán Böszörményi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 652158] Use of :locked is deprecated
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=652158 Jan ONDREJ ondr...@salstar.sk changed: What|Removed |Added CC||fedora-perl-devel-l...@redh ||at.com, tcall...@redhat.com Component|mrtg|perl-Net-SNMP AssignedTo|vcrho...@redhat.com |tcall...@redhat.com --- Comment #1 from Jan ONDREJ ondr...@salstar.sk 2010-11-11 03:03:01 EST --- Sorry, looks like wrong component was chosen. Changing component to perl-Net-SNMP. -- 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
