Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote: On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. Some people what that. Many other people want the focus change to happen in a _few_ limited cases where it makes sense. Current behaviour fails to accurately predict those cases (no doubt because, in part, the limited acceptable cases differ from person to person), and so you get unexpected focus theft. This is bad for everyone. The problem is that the automatic focus change only when intended by user will never be done 100% correctly. This is just impossible to do. So the actual better user experience case would be to always require the user to press some (easy) key combination to transfer the focus from the currently focused window. The user would quickly learn it. Then the problem shifts to whether the newly created windows should be opened in the background or not. It would be also easy to teach the user. I can for example imagine that the new window would first appear on the top overlayed with a semi-transparent text like: Press Ctrl-Tab to send the window to background, press Alt-Tab to start typing into the window, press Esc to close the window The other keypresses would still go to the previously focused window. With the compositing WMs it would be also easily possible to make the new window semitransparent over the old window so the user would still see that he is typing into the old window. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote: So to make this a reality, we need to ensure that whatever is in rawhide has a *=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was = whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a newer ENVR than that same package in any of the newer distros. Yes, but it may happen before the bodhi stage, when we get autoqa working on post-build tests. This kind of check could happen at SCM commit time, package build time, or finally bodhi push time. Seems reasonable that we'd want to catch it as early as possible, but that does force people to work on rawhide first, then work on the pending release which may be under critical time pressure. Certainly something to discuss. Catching it at bodhi time seems too late. We could allow adding numbers after the dist tag in release for this purpose. And if the fixed package would upgrade to a newer upstream version it should not be too big hassle to build it in the rawhide tree first. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 13:39 -0500, Rex Dieter wrote: Tomas Mraz wrote: We could allow adding numbers after the dist tag in release for this purpose. That is already allowed, and encouraged, for branch-specific modfications, http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches Heh, dunno why I thought it is disallowed. Then I don't see any problem with enforcing n-v-r ordering during cvs tagging. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On Tue, 2009-10-20 at 08:45 +0200, Ralf Ertzinger wrote: Hi. I was wondering the other day how much space the file information (i.e. the stuff that rpm -V checks against) takes up in an RPM file. And, going from there, how much space we would waste over the years if we kept this information for every RPM ever built by koji. The idea would be to have a database of known good file information that is separate from the local RPM database, so one may burn this information to a bootable CD (or DVD) to be able to verify the integrity of the local files (as long as the files came from a fedora built RPM file, that is). Another possibility would be to load the information from the net, on demand. How much data are we talking about, roughly? What would this be good for? Actually for some files it would be a known bad file hashes because these files (binaries or scripts) would contain known vulnerabilities and so knowing that you have a file that was once included in Fedora does not guarantee you almost anything. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On Tue, 2009-10-20 at 10:45 +0200, Ralf Ertzinger wrote: Hi. On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote: What would this be good for? Actually for some files it would be a known bad file hashes because these files (binaries or scripts) would contain known vulnerabilities and so knowing that you have a file that was once included in Fedora does not guarantee you almost anything. I'm not sure I follow you here. Containing a known vulnerability in a binary file has nothing to do with the hash. I simply meant that if the attacker wanted to compromise your system he could just revert some binary or script to a vulnerable version which was previously included in Fedora. So having the files on your system to match hashes from older package releases does not provide you any security. For a real security you need to match the hashes against current package versions. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux disabled in rawhide ?
On Sun, 2009-09-13 at 19:28 -0400, Daniel J Walsh wrote: On 09/12/2009 12:13 PM, Dave Jones wrote: I did two installs yesterday, and both of them have ended up with SELINUX=disabled in /etc/selinux/config I changed them back to 'enabled', rebooted, which caused a relabel, and all seems fine. What's happening here ? Dave I don't know there was a bug in dracut that was causing selinux to be disabled. Dan, do you mean the https://bugzilla.redhat.com/show_bug.cgi?id=520753 ? But this one looks like a different bug perhaps in anaconda? At least it seems to be worth reporting it to bz on anaconda. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Policy on removing %changelog entries?
On Thu, 2009-08-27 at 13:21 -0400, Jeff Garzik wrote: What is the policy regarding deletion of individual entries in the middle of %changelog? A developer added a %changelog entry to each of my cloud daemons' packages, on the main fedora-cvs devel branch of each. Then, a day or so later, after other %changelog entries had been added by me... the same developer removed one %changelog entry from the middle of %changelog, and added another entry at the top. I thought the policy was to never delete %changelog entries, ever? I've explained that the reason for removing that entry was that the package for which the changelog entry I've added first was never on the rawhide dist tag in koji. And as it was necessary to do another rebuild so the entry could be seen as duplicate I've removed that previous entry. However I understand that you don't want that to happen again so I won't do it again. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssl packages in dist-f12 (Was: rawhide report: 20090822 changes)
On Sat, 2009-08-22 at 18:15 +0300, Kalev Lember wrote: Rawhide Report wrote: ctorrent-1.3.4-12.dnh3.3.2.fc12 --- * Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 1.3.4-11.dnh3.3.2 - rebuilt with new openssl * Fri Aug 21 2009 Dominik 'Rathann' Mierzejewski r...@greysector.net 1.3.4-12.dnh3.3.2 - fixed stack-based buffer overflow (CVE-2009-1759, RHBZ #501813) m2crypto-0.20-2 --- * Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 0.20-2 - rebuilt with new openssl mail-notification-5.4-14.fc12 - * Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 5.4-13 - rebuilt with new openssl * Fri Aug 21 2009 Dmitry Butskoy dmi...@butskoy.name - 5.4-14 - add gtkhtml3-devel pkgconfig requirements into config stuff for evolution plugin build * Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 5.4-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild ptlib-2.6.4-3.fc12 -- * Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 2.6.4-3 - rebuilt with new openssl xorg-x11-server-1.6.99-39.20090820.fc12 --- * Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 1.6.99-38.20090820 - rebuilt with new openssl * Fri Aug 21 2009 Adam Jackson a...@redhat.com 1.6.99-39.20090820 - xserver-1.6.99-default-modes.patch: Don't add default modes to the pool if the driver returned real modes (and has no EDID). * Thu Aug 20 2009 Adam Jackson a...@redhat.com 1.6.99-37.20090820 - Today's git snapshot. - xserver-1.6.99-dri2-swapbuffers-fallback.patch: Fix SwapBuffers crash. - xserver-1.6.99-linkmap.patch: Drop, superceded upstream. - xserver-1.6.1-proc-cmdline.patch, xserver-1.6.99-dpms.patch, xserver-1.6.99-eventtime.patch: Drop, merged. Those 5 packages seem to have ended up in dist-f12 instead of dist-f12-openssl where other packages are being rebuilt. Yes, please if you encounter the openssl rebuild changelog in the and do not need your new build to land into the public rawhide repository as soon as possible, please use TARGET=dist-f12-openssl. If you need it to land into public rawhide then use no TARGET (dist-f12) as usual. After I resolve the failed rebuilds and be ready for the mass tag move of the rebuilt packages I'll check whether there are not some newer rebuilds in dist-f12 anyway and rebuild them appropriately. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
openssl rebuilds where is Tomas on 2009-08-24
Hi, I've spent whole day today (Sat 22) resolving build failures on dependent packages after the openssl-1.0.0 upgrade. I will continue on the remaining openssl rebuild fixes after I return from the short trip I want to go tomorrow and on Monday. There is still about 30 packages which are not yet rebuilt. If you have a package which failed a rebuild and want to look at it you can try building it into dist-f12-openssl after patching the API calls. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Soname bump for openssl
Hi all, I'd like to upgrade OpenSSL to 1.0.0-beta3 version just after the F12 Alpha release. I asked rel-eng to create a custom build target for the rebuild so we can avoid shipping the symlink hacks in rawhide. The API did not change in a way it would break any sensible user's of the API, so no patches to the dependent packages are expected to be necessary. Unfortunately as this is major version upgrade the ABI changed. I know that the upgrade would be better before the F12 Alpha however it required major patch porting for the FIPS validation related code which is not included in the upstream 1.0.0 branch. I was unfortunately not able to complete this porting before Alpha Freeze. As always I will rebuild all the dependent packages if you do not ask me otherwise for your package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Soname bump for openssl
On Wed, 2009-08-12 at 07:36 -0400, Josh Boyer wrote: On Wed, Aug 12, 2009 at 11:45:50AM +0200, Tomas Mraz wrote: Hi all, I'd like to upgrade OpenSSL to 1.0.0-beta3 version just after the F12 Alpha release. I asked rel-eng to create a custom build target for the rebuild so we can avoid shipping the symlink hacks in rawhide. A few questions: Why a beta version? Because the changes on the 1.0.0 branch will not break ABI as they will be bugfix-only and it will allow us to upgrade to 1.0.0 later. Is there a good chance the final upstream release will be done before F12 GAs? Yes, there is, but of course I cannot guarantee that. But it shouldn't be a problem too big as the beta3 is already in pretty good shape. Will the beta nature of the release cause lots of potential rebuilds as you update it with newer betas? If you mean rebuilds of dependencies then definitely not. And even rebuilds of openssl there should not be many as I suppose there will be a final release soon. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Soname bump for openssl
On Wed, 2009-08-12 at 09:47 -0400, Josh Boyer wrote: On Wed, Aug 12, 2009 at 03:38:27PM +0200, Tomas Mraz wrote: On Wed, 2009-08-12 at 07:36 -0400, Josh Boyer wrote: On Wed, Aug 12, 2009 at 11:45:50AM +0200, Tomas Mraz wrote: Hi all, I'd like to upgrade OpenSSL to 1.0.0-beta3 version just after the F12 Alpha release. I asked rel-eng to create a custom build target for the rebuild so we can avoid shipping the symlink hacks in rawhide. A few questions: Why a beta version? Because the changes on the 1.0.0 branch will not break ABI as they will be bugfix-only and it will allow us to upgrade to 1.0.0 later. Thanks for the quick response! One more question: Are we planning for a compat- package for the current OpenSSL version? I currently do not plan it - we did not do it for recent OpenSSL soname bumps either, however I would not object if anyone wants to make the compat package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crontab configuration
On Wed, 2009-08-05 at 17:42 -0400, Ricky Zhou wrote: On 2009-08-05 04:32:57 PM, Mike Chambers wrote: Ok, in F11 it had /etc/anacrontab file that I could edit to get my cron.daily time to be set. But I don't see that file and can't find where the time is set that I want it ran from. I believe it was 4am this morning when it ran but I don't know where that time to run came from? My random guess from an rpm -ql cronie is /etc/regularly-jobs. All these anacron/crontab changes should hopefully be mentioned the release notes somehow :-/ Yes, however this name change will be reverted in the next upstream cronie release due some time during the next week. This change is too confusing to users. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tue, 2009-06-16 at 11:42 -0400, Bill Nottingham wrote: Chris Adams (cmad...@hiwaay.net) said: Removing support for still-functional hardware is a trademark of Microsoft, not Linux. I'd also argue that doing another full rebuild of the OS for a 1% performance gain on a single architecture is not a particularly production use of resources. The 1% comes from i586 - i686; SSE2 would be additional on top of that. But given the vehement opposition, I can see dropping the SSE2 requirement. I'm still fairly convinced that going to i686 is the right move - we really don't support i586 as a practical matter, and even the Geode should still work with that. Furthermore, it's likely we'll have a mass rebuild for LZMA support and/or debuginfo changes, so it's no additional cost. Great, i686 without SSE(2) seems OK to me. I even wonder why we did not go to that requirement in F11 already without the intermediate ~i586 requirement. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Mon, 2009-06-15 at 20:01 +0100, Jeremy Sanders wrote: Bill Nottingham wrote: - Faster and more consistent FP math by using SSE2 registers - Allows for autovectorization by GCC where necessary - More clearly delineates our support set of targets, sticking true to forwards innovation, not necessarily legacy support Why not leave it be and suggest people move to the less brain dead x86-64 instead? Innovation and legacy support. The slower x86 is, the more motivation there is to move to x86-64. +1 In the other thread there is ongoing discussion about dropping/not dropping split CDs install media and we want to drop support for processors without SSE2? Please no. Moving from the current i586 to pure i686 would not be so painful but I suppose it would not bring much benefit in terms of performance gain. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Tue, 2009-05-26 at 09:06 +0100, Richard W.M. Jones wrote: On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like to orphan it. I might stay as a comaintainer if you want. It looks like Warren Togami has jumped in there to be co-maintainer. If you need someone else I can help. Rich. wait what? Why are you volunteering me for something I know nothing about? A simple misunderstanding - I looked at the ACLs and noticed that you were there already, so I assumed you'd already taken co-maint for the package. Tomas: If you still want me to co-maintain this package, let me know. I'll orphan it and you can be the primary maintainer. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Anybody interested in vpnc
Hi fellow packagers, is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like to orphan it. I might stay as a comaintainer if you want. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[SECURITY] Fedora Core 3 Update: pam-0.77-66.2.13
- Fedora Update Notification FEDORA-2005-1030 2005-10-26 - Product : Fedora Core 3 Name: pam Version : 0.77 Release : 66.2.13 Summary : A security tool which provides authentication for applications. Description : PAM (Pluggable Authentication Modules) is a system security tool that allows system administrators to set authentication policy without having to recompile programs that handle authentication. - Update Information: This update fixes a security bug in unix_chkpwd allowing brute force attacks against passwords in /etc/shadow by a regular user when SELinux is enabled. - * Wed Oct 26 2005 Tomas Mraz [EMAIL PROTECTED] 0.77-66.2.13 - fixed CAN-2005-2977 unix_chkpwd should skip user verification only if run as root (#168181) - support no tty in pam_access (#170467) - support unlimited limits (#171546) - allow larger buffer for getgr* functions - flush input first, then print the prompt in misc_conv - improve the passwd-order patch so it doesn't regress passwd on the NIS master server * Mon Jan 24 2005 Tomas Mraz [EMAIL PROTECTED] - ALLGROUP and ALL limits weren't correctly applied by pam_limits - Fix a typo in pam_localuser README - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ d1a8c71517ac457b12522906b5ca00e4 SRPMS/pam-0.77-66.2.13.src.rpm bf60d28835a86303ec733ebd9ded454c x86_64/pam-0.77-66.2.13.x86_64.rpm a5ca72723f4141b7af15b9fc0e2f2411 x86_64/pam-devel-0.77-66.2.13.x86_64.rpm cea2cac58b70de0e8b692dbd5687be32 x86_64/debug/pam-debuginfo-0.77-66.2.13.x86_64.rpm 7f888626b9ec2ec25ad5871366974b92 x86_64/pam-0.77-66.2.13.i386.rpm 2178f2baec355d9096b751f03d0f0ed7 x86_64/pam-devel-0.77-66.2.13.i386.rpm 7f888626b9ec2ec25ad5871366974b92 i386/pam-0.77-66.2.13.i386.rpm 2178f2baec355d9096b751f03d0f0ed7 i386/pam-devel-0.77-66.2.13.i386.rpm 0e2577415f68615d088d5d6fdbd303ab i386/debug/pam-debuginfo-0.77-66.2.13.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 3 Update: openssl-0.9.7a-42.2
- Fedora Update Notification FEDORA-2005-985 2005-10-13 - Product : Fedora Core 3 Name: openssl Version : 0.9.7a Release : 42.2 Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. - * Tue Oct 11 2005 Tomas Mraz [EMAIL PROTECTED] 0.9.7a-42.2 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - more fixes for constant time/memory access for DSA signature algorithm - updated ICA engine patch - install ca-bundle.crt as a config file - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ 385070cd4cbcef6beb59571066a08baf SRPMS/openssl-0.9.7a-42.2.src.rpm dd28b6aba5377c64da20c05e2c60722e x86_64/openssl-0.9.7a-42.2.x86_64.rpm 062d09908f387958b35c71112215 x86_64/openssl-devel-0.9.7a-42.2.x86_64.rpm cf47c8a41605ee78213f0ed54b81d01c x86_64/openssl-perl-0.9.7a-42.2.x86_64.rpm 7dd0586966ce231751013a66050c1cd1 x86_64/debug/openssl-debuginfo-0.9.7a-42.2.x86_64.rpm 5771664b0590b304c5d2a06dba276642 x86_64/openssl-0.9.7a-42.2.i386.rpm 797ddd44ea165b234463a80107f14f18 x86_64/openssl-0.9.7a-42.2.i686.rpm 5771664b0590b304c5d2a06dba276642 i386/openssl-0.9.7a-42.2.i386.rpm 26a292002e9806eb6331ade376c04c68 i386/openssl-devel-0.9.7a-42.2.i386.rpm 1c2676b06b305fcc3e82b79a641cdbb7 i386/openssl-perl-0.9.7a-42.2.i386.rpm a8599ed6c62d679dc4f5aa4bd0b63131 i386/debug/openssl-debuginfo-0.9.7a-42.2.i386.rpm 797ddd44ea165b234463a80107f14f18 i386/openssl-0.9.7a-42.2.i686.rpm ac7dd0ec8c3e1d57b580ceffce7f37bb i386/debug/openssl-debuginfo-0.9.7a-42.2.i686.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 4 Update: openssl-0.9.7f-7.10
- Fedora Update Notification FEDORA-2005-986 2005-10-13 - Product : Fedora Core 4 Name: openssl Version : 0.9.7f Release : 7.10 Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. - * Wed Oct 12 2005 Tomas Mraz [EMAIL PROTECTED] 0.9.7f-7.10 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - more fixes for constant time/memory access for DSA signature algorithm - updated ICA engine patch - ca-bundle.crt should be config(noreplace) - add *.so.soversion as symlinks in /lib (#165264) - remove unpackaged symlinks (#159595) - fixes from upstream (bn assembler div on ppc arch, initialize memory on realloc) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/ 7a208caac25c849bea298129a50cd07b SRPMS/openssl-0.9.7f-7.10.src.rpm 59019192fd5257073275df66aba0ed9c ppc/openssl-0.9.7f-7.10.ppc.rpm 3efb44c6fa9b7ede9d6bf6ede9aabd16 ppc/openssl-devel-0.9.7f-7.10.ppc.rpm 78e9dc41a9f7da959c79a6b47b364e7c ppc/openssl-perl-0.9.7f-7.10.ppc.rpm dfd846c61dba5ade1414c5cc40d08014 ppc/debug/openssl-debuginfo-0.9.7f-7.10.ppc.rpm 28be950fca37f2778cb68e18572f3e13 ppc/openssl-0.9.7f-7.10.ppc64.rpm 97ffac074c3e0efc99110726eb6cf3cf x86_64/openssl-0.9.7f-7.10.x86_64.rpm f7e8e31bfac9e30124850913244b9c1a x86_64/openssl-devel-0.9.7f-7.10.x86_64.rpm 7e6528df16fb831ba79e6faeeea5125a x86_64/openssl-perl-0.9.7f-7.10.x86_64.rpm d421465583f86241aebd04dc9616fc6e x86_64/debug/openssl-debuginfo-0.9.7f-7.10.x86_64.rpm 10b0af84502fa18f9894e9e759cecd64 i386/openssl-0.9.7f-7.10.i386.rpm b68877aac95d2066a8880495d96b6105 i386/openssl-devel-0.9.7f-7.10.i386.rpm 752088e010d088efcb8a8d433e7e2814 i386/openssl-perl-0.9.7f-7.10.i386.rpm aac366e42a46f27c7136e6c4dc602278 i386/debug/openssl-debuginfo-0.9.7f-7.10.i386.rpm 4af1e37b0caba144bd44df07af5f33fb i386/openssl-0.9.7f-7.10.i686.rpm 38e486decdc14d578975079e573202de i386/debug/openssl-debuginfo-0.9.7f-7.10.i686.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 4 Update: openssl097a-0.9.7a-3.1
- Fedora Update Notification FEDORA-2005-986 2005-10-13 - Product : Fedora Core 4 Name: openssl097a Version : 0.9.7a Release : 3.1 Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. - * Tue Oct 11 2005 Tomas Mraz [EMAIL PROTECTED] 0.9.7a-3.1 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - more fixes for constant time/memory access for DSA signature algorithm - updated ICA engine patch - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/ 7b5d366a2175f506df5470052584f931 SRPMS/openssl097a-0.9.7a-3.1.src.rpm af1d476f7115ee75d213daa91bb42808 ppc/openssl097a-0.9.7a-3.1.ppc.rpm 2b51057a778da0e5cd3ce961499fd4e7 ppc/debug/openssl097a-debuginfo-0.9.7a-3.1.ppc.rpm aeaeb2f3d8bc9f2a58a54c7fdead02f8 x86_64/openssl097a-0.9.7a-3.1.x86_64.rpm 5bb4865bf5b279349115cd4327939d8c x86_64/debug/openssl097a-debuginfo-0.9.7a-3.1.x86_64.rpm 89142415f683cf15a74b1b6cf8fcaeda i386/openssl097a-0.9.7a-3.1.i386.rpm 6d9052a438a4e279baf5e3e633502fe0 i386/debug/openssl097a-debuginfo-0.9.7a-3.1.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 3 Update: openssl096b-0.9.6b-21.2
- Fedora Update Notification FEDORA-2005-985 2005-10-13 - Product : Fedora Core 3 Name: openssl096b Version : 0.9.6b Release : 21.2 Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. - * Thu Oct 6 2005 Tomas Mraz [EMAIL PROTECTED] 0.9.6b-21.2 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - more fixes for constant time/memory access for DSA signature algorithm - replaced add-luna patch with new one with right license (#158061) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ a81510ddd8127092def521888a29735c SRPMS/openssl096b-0.9.6b-21.2.src.rpm a16e20e80018c7676260339fd9d5dec1 x86_64/openssl096b-0.9.6b-21.2.x86_64.rpm fa00e72e190651d0c6c28bb197c15661 x86_64/debug/openssl096b-debuginfo-0.9.6b-21.2.x86_64.rpm 515e5aa803873859c235d0822ab74710 x86_64/openssl096b-0.9.6b-21.2.i386.rpm 515e5aa803873859c235d0822ab74710 i386/openssl096b-0.9.6b-21.2.i386.rpm d892c00a0272ede0a0f625f5ae746313 i386/debug/openssl096b-debuginfo-0.9.6b-21.2.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 4 Update: openssh-4.2p1-fc4.1
- Fedora Update Notification FEDORA-2005-860 2005-09-12 - Product : Fedora Core 4 Name: openssh Version : 4.2p1 Release : fc4.1 Summary : The OpenSSH implementation of SSH protocol versions 1 and 2. Description : OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. Public key authentication may be used for passwordless access to servers. This package includes the core files necessary for both the OpenSSH client and server. To make this package useful, you should also install openssh-clients, openssh-server, or both. - Update Information: This security update fixes CAN-2005-2797 and CAN-2005-2798 and resolves a problem with X forwarding binding only on IPv6 address on certain circumstances. As it is an upgrade to a newer upstream release there is a small change in interoperability with ssh clients older than 3.5p1 if they are configured so they insist on compression. If interoperability with such clients is required, the Compression option must be set to yes. - * Wed Sep 7 2005 Tomas Mraz [EMAIL PROTECTED] 4.2p1-fc4.1 - upgrade to a new upstream version - don't use X11 port which can't be bound on all IP families (#163732) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/ 00805dac96c841cbfd40170022190619 SRPMS/openssh-4.2p1-fc4.1.src.rpm 0e3920148be386e1ad059a36203a2ad4 ppc/openssh-4.2p1-fc4.1.ppc.rpm b43f94f610df46c8d2906a1fd9c66426 ppc/openssh-clients-4.2p1-fc4.1.ppc.rpm 5cdd6f0de550be0100118c1e1edda6be ppc/openssh-server-4.2p1-fc4.1.ppc.rpm 72b2eb642aab64911f129c2f1bbd7c87 ppc/openssh-askpass-4.2p1-fc4.1.ppc.rpm 7dcfd13cedac17596625d9131bb0ec92 ppc/openssh-askpass-gnome-4.2p1-fc4.1.ppc.rpm 3f8eeae5e885288ab0eabba60eab049f ppc/debug/openssh-debuginfo-4.2p1-fc4.1.ppc.rpm bc455ca2e0efba438e17b2ee3f558ff2 x86_64/openssh-4.2p1-fc4.1.x86_64.rpm e92b67a22a9a86f710ba6310de3ba646 x86_64/openssh-clients-4.2p1-fc4.1.x86_64.rpm 5b676585808c1d3dccd4220c13314507 x86_64/openssh-server-4.2p1-fc4.1.x86_64.rpm eb91cc04ca4e8a72a271a555d40c023b x86_64/openssh-askpass-4.2p1-fc4.1.x86_64.rpm ab86ad7914bbf360be0d2356e3727c6d x86_64/openssh-askpass-gnome-4.2p1-fc4.1.x86_64.rpm afb0acbb94a568463662ea4af55f4cb6 x86_64/debug/openssh-debuginfo-4.2p1-fc4.1.x86_64.rpm 8863fa64f0bf415de311407840f6ad2d i386/openssh-4.2p1-fc4.1.i386.rpm 1ab4c1ff99c6ec2975510ad811beeb41 i386/openssh-clients-4.2p1-fc4.1.i386.rpm 8402e25877a6e0d78d960ce53a44250d i386/openssh-server-4.2p1-fc4.1.i386.rpm e8ff043f0383a740f391b4c71a4b869a i386/openssh-askpass-4.2p1-fc4.1.i386.rpm 67991f582615c924a529eb63b9910d29 i386/openssh-askpass-gnome-4.2p1-fc4.1.i386.rpm 3876419031aabbfe4aecc5d1e82dfa11 i386/debug/openssh-debuginfo-4.2p1-fc4.1.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list
[SECURITY] Fedora Core 3 Update: openssh-3.9p1-8.0.3
- Fedora Update Notification FEDORA-2005-858 2005-09-07 - Product : Fedora Core 3 Name: openssh Version : 3.9p1 Release : 8.0.3 Summary : The OpenSSH implementation of SSH protocol versions 1 and 2. Description : OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. Public key authentication may be used for passwordless access to servers. This package includes the core files necessary for both the OpenSSH client and server. To make this package useful, you should also install openssh-clients, openssh-server, or both. - Update Information: This security update fixes CAN-2005-2798 and resolves a problem with X forwarding binding only on IPv6 address on certain circumstances. - * Wed Sep 7 2005 Tomas Mraz [EMAIL PROTECTED] 3.9p1-8.0.3 - destroy creds if gssapi authentication fails - CAN-2005-2798 (#167444) - don't use X11 port which can't be bound on all IP families (#163732) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ c42c4bf11075a5bc6787427f6f1bbdb7 SRPMS/openssh-3.9p1-8.0.3.src.rpm 65e54cc979b888208a1783018fa2141f x86_64/openssh-3.9p1-8.0.3.x86_64.rpm aa95f00bd8aee18f1d7709a655dd2900 x86_64/openssh-clients-3.9p1-8.0.3.x86_64.rpm 4c0fdd9c8c8239b47500344fe2a36eae x86_64/openssh-server-3.9p1-8.0.3.x86_64.rpm c136972b79ba963b8982e90d941a6d25 x86_64/openssh-askpass-3.9p1-8.0.3.x86_64.rpm 6cbf80015a4189468f81e0e58847fe75 x86_64/openssh-askpass-gnome-3.9p1-8.0.3.x86_64.rpm 0fee7f443f1fe6c9e481ac5fb848d83d x86_64/debug/openssh-debuginfo-3.9p1-8.0.3.x86_64.rpm b2be46aac023e5a2acb035abe299ff51 i386/openssh-3.9p1-8.0.3.i386.rpm 225aa0a619a500eef68c50dc6904584e i386/openssh-clients-3.9p1-8.0.3.i386.rpm 1f961d9889ca730e41094c68df4576fe i386/openssh-server-3.9p1-8.0.3.i386.rpm abb099c7505111ea5504066413bad8e8 i386/openssh-askpass-3.9p1-8.0.3.i386.rpm 58e19672af45d282ffd664280c77572d i386/openssh-askpass-gnome-3.9p1-8.0.3.i386.rpm d1a3004d2cdf7b6f89ba2aa4e6d2fbd3 i386/debug/openssh-debuginfo-3.9p1-8.0.3.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list
