January 2005 - openSUSE Security - openSUSE Mailing Lists

Howto force an account to change its password at next logon?
by Daniel Wirth 27 Jan '05

27 Jan '05

Dear list, we try to implement an operator proof solution to force a user to change his password at the next logon. The only way we found is: - manually alter the password creation date in /etc/shadow to a date in the past - set an coresponding password expiration period (so that the password has already expired) Do you know any nice GUI-tools to set the password creation date in /etc/shadow? Or is there any easier way to implement this? Thanks in advance Daniel

2 1

RE: [suse-security] Howto force an account to change its password at next logon?
by Ness, Todd 27 Jan '05

27 Jan '05

# passwd --help Usage: passwd [-f|-g|-s|-k[-q]] [name] passwd [-n min] [-x max] [-w warn] [-i inact] user passwd {-l|-u|-d|-S[-a]|-e|-h} user passwd - change password information -f Change the finger (gecos) information -h Change the home directory -s Change the login shell -g Change the group password -k Change the password only if expired -q Try to be quiet -S Show the password attributes -a Only with -S, show for all accounts -d Delete the password for the named account -l Locks the password entry for "user" -u Try to unlock the password entry for "user" -e Force the user to change password at next login -n min Set minimum field for "user" -x max Set maximum field for "user" -w warn Set warn field for "user" -r service Use nameservice 'service' --help Give this help list --usage Give a short usage message --version Print program version Valid services for -r are: files, nis, nisplus, ldap I believe that "passwd -e " would be the best way to do this. Although not a GUI solution, how much more simple can it get. -----Original Message----- From: Daniel Wirth [mailto:dw@wirthuell.de] Sent: Thursday, January 27, 2005 9:34 AM To: suse-security(a)suse.com Subject: [suse-security] Howto force an account to change its password at next logon? Dear list, we try to implement an operator proof solution to force a user to change his password at the next logon. The only way we found is: - manually alter the password creation date in /etc/shadow to a date in the past - set an coresponding password expiration period (so that the password has already expired) Do you know any nice GUI-tools to set the password creation date in /etc/shadow? Or is there any easier way to implement this? Thanks in advance Daniel -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help(a)suse.com Security-related bug reports go to security(a)suse.de, not here

2 1

SuSE-firewall with webserver and samba
by Birgit Kellner 27 Jan '05

27 Jan '05

Hello, I'm trying to configure a webserver (SuSE 9.1), with a SUSE firewall, and perhaps also with samba fileshares, though I'm not sure there's a reasonably secure way of doing this. ssh should also be accessible. There is no internal (private) network. The server, and the machines accessing the fileshares, are part of a university network. All machines access the internet through that network; nothing from them (or to them) goes through the firewall, which should only protect the machine running the webserver and the samba shares. The server host and the samba clients belong to the same DNS subdomain, and have an IP address block like 222.222.222.2 - 222.222.222.126. The clients all run Windows NT 4.0, Windows 2000, or Windows XP. As I've currently configured the system, I have two problems: (1) some users from outside report that the webserver is not accessible; connection attempts throw up DNS errors. I have no rejected packets for port 80 in the firewall log, and am therefore inclined to think that the problem is not with the server or firewall configuration. From within the university network, I have no problems connecting to the server on port 80. Could it be that it just takes some time until the DNS information for the server spreads around, or does this entail that there's something wrong with the DNS entry for the server? (2) the samba fileshares can't be accessed. Actually, there's only one fileshare. Only one particular username is accepted as valid, and the samba clients must belong to the IP block 222.222.222.xxx/25. The firewall configuration file currently looks as follows: FW_QUICKMODE="no" FW_DEV_EXT="eth0" FW_DEV_INT="" FW_MASQUERADE="no" FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="www ssh 139 137 138 445" FW_SERVICES_EXT_UDP="" FW_SERVICES_EXT_IP="" FW_SERVICES_INT_TCP="" FW_SERVICES_INT_UDP="" FW_SERVICES_INT_IP="" FW_TRUSTED_NETS="222.222.222.0/25,tcp,137 222.222.222.0/25,tcp,138 222.222.222.0/25,tcp,139 222.222.222.0/25,tcp,445 222.222.222.0/25,udp,137 222.222.222.0/25,udp,138 222.222.222.0/25,udp,139" FW_ALLOW_INCOMING_HIGHPORTS_TCP="dns" FW_ALLOW_INCOMING_HIGHPORTS_UDP="dns" FW_SERVICE_AUTODETECT="yes" FW_SERVICE_SAMBA="yes" FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="yes" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_KERNEL_SECURITY="yes" FW_ALLOW_PING_FW="no" FW_ALLOW_PING_EXT="no" My idea was to define the ip block of the samba clients as a "trusted net", and to only open the required tcp/udp ports, which are (I believe) 137-139 and 445. I'm not sure whether my syntax for FW_TRUSTED_NETS is correct. But would the general approach be ok? And are there any other non-sensical or counterproductive settings? Thanks a lot; I'm very new at this (as one might perhaps have gathered from the configuration ...), best regards, Birgit Kellner

2 1

SELinux Support in SuSE 9.2
by Tedi Heriyanto 27 Jan '05

27 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I am currently learning about SELinux. Do I just need to do the following to enable SELinux in SuSE 9.2 : - - change the entry in kernel option in grub/lilo config to "selinux=1" - - install libselinux Thank you very much - -- Tedi Heriyanto URL : www.tedi-h.com GPG fingerprint = C02C 7797 0EF0 5D25 798A 0A25 1DD3 6924 57C7 5D78 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB928WHdNpJFfHXXgRAmYUAKCKhNEJQWutpE1Hvveympo+4wcqXACgjctJ dDSpHpaifPDpO5/ygc6GkRY= =DcAn -----END PGP SIGNATURE-----

2 3

WLan ->(Intranet) ->Internet Howto?
by Andreas Paulick 25 Jan '05

25 Jan '05

Hello there, I have read the last days the Inet about security stuff (VPN-Howto, VPN-Masq-Howto) and got more and more confused. I want share my inet-dialup-connection with my neighbour across the street. He has a Win98SE-PC with a WLan-network-card and here will stay a standard access point. Because Win98, there are some difficults to establish a WPA-Connection. If I test with another client, the Wlan-speed with WPA enabled is awfull slow (as expected from this cheap AP here) But thats not the way we're want to go. We want a solution to keep the kiddys and normal crackers out. (I think a real Hacker doesnt give up if he sees a VPN). So I want to secure this connection with a VPN-connection. But where to start? There are no win98-clients for IPsec out there, but there is an L2TP-client. There are Firewall / Masquerade problems with VPN.... For the right way to split up the secure zones I will set the router like this: !--------------------! clients---Intranet-----!eth1 ROUTER eth0!---DSL/ISP---> via Cat5 Hub ! with FW, ! ! VPN-server ! client-----WLAN-AP-----!eth2 ! with Wlan !--------------------! +VPN-client Is this overkilled (additional Network-Card) or easier to configure? Im afraid, there are much concerns to care about, if I plug the WLAN-AP direct to the Intranet-Hub. What Server/client would you suggest to use for VPN (keep in mind the client-soft have to run on Win98SE)? Have I care about firewall concerns at eth2? As is see, there should only one piece of software listen on this network interface: the VPN-server. Because I decrypt the traffic on my router, have I worry about masqueradeing the traffic to/ from the public Inet? How could I prevent the VPN-Users from any services in the Intranet exept for the forwaring to the public Inet? Could you point me either to a howto or a software path ("Take client XXyyzz from MicroLinux, take server freegoose from SuseSoft and glue them together" or some raw main points to look for? thanks in advantage Andy

3 2

Re: [suse-security] errata page
by Niki Rahimi 25 Jan '05

25 Jan '05

Marcus wrote: >On Tue, Jan 25, 2005 at 02:42:46PM -0600, Niki Rahimi wrote: >> Hi All, >> Would anyone know of an errata page with security vulnerabilities >> and other issues listed that one >> could look up within the suse.com or .de pages? I'm also open to non SuSE >> pages but would prefer one >> directly from the company. >Just go to www.suse.de (which links to Novell) and click on SUSE Linux >Security. >Ciao, Marcus Terrific! I was looking on suse.com before. This is great info. Thanks much!! Niki A. Rahimi IBM Premium Services Advanced Support narahimi(a)us.ibm.com

1 0

errata page
by Niki Rahimi 25 Jan '05

25 Jan '05

Hi All, Would anyone know of an errata page with security vulnerabilities and other issues listed that one could look up within the suse.com or .de pages? I'm also open to non SuSE pages but would prefer one directly from the company. Thanks, Niki Niki A. Rahimi IBM Premium Services Advanced Support narahimi(a)us.ibm.com

2 1

product lifecycle for SuSE 8.2
by Bob Vickers 25 Jan '05

25 Jan '05

Hello, I'm trying to do some forward planning and I've scoured the SuSE website trying to find out when we will stop getting security updates for SuSE 8.2. I know it's quite soon because 8.2 came out roughly in spring 2003 and there is a 2-year lifecycle: does anyone have a more accurate date? Thanks, Bob ============================================================== Bob Vickers R.Vickers(a)cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691

2 1

SUSE Security Announcement: Realplayer 8 (SUSE-SA:2005:004)
by Marcus Meissner 24 Jan '05

24 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SUSE Security Announcement Package: realplayer 8 Announcement-ID: SUSE-SA:2005:004 Date: Monday, Jan 24th 2005 16:00 MET Affected products: 8.1, 8.2, 9.0, 9.1 SUSE Linux Desktop 1.0 Vulnerability Type: remote code execution Severity (1-10): 8 SUSE default package: yes Cross References: none Content of this advisory: 1) security vulnerability discussed: - integer overflow problem description 2) solution/workaround 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion RealPlayer is a combined audio and video player for RealMedia formatted streaming data. These formats are very common throughout the Internet. eEye Security in October 2004 discovered a flaw in the .rm RealMovie stream handling routines which allows a remote attacker to exploit an integer overflow vulnerability using a special .rm file. This might allow a remote attacker to execute code as the user running RealPlayer. Reference URLs for this problems are the Real security advisory: http://service.real.com/help/faq/security/040928_player/EN/ and the eEye security advisory: http://www.eeye.com/html/research/advisories/AD20041001.html SUSE Linux includes RealPlayer as both standalone player and as a plugin for web browsers like Mozilla and Konqueror. This might allow the attacker to just provide a web page or E-Mail linking to the special exploit .rm file. We cannot fully evaluate the impact of this problem due to lack of information and lack of source code to review. SUSE Linux versions up to 9.1 and the SUSE Linux Desktop 1.0 include RealPlayer version 8 and are affected by this problem. SUSE Linux 9.2 and the Novell Linux Desktop 9 include RealPlayer version 10 and are NOT affected by this problem. Real does not offer a fixed version 8 RealPlayer, but suggests upgrading RealPlayer to version 10. However, upgrading Realplayer is not possible for older SUSE Linux products since Realplayer 10 requires newer dynamic library versions than the ones to be found in those products. Also some old Real content is not compatible with the RealPlayer version 10. For these reasons we cannot offer fixed packages for older SUSE Linux based products. 2) solution/workaround We suggest one of the following workarounds: a) De-install RealPlayer Either use YaST to deinstall RealPlayer, or as root do: # rpm -e RealPlayer You will lose the ability to view Real content. b) Remove the RealPlayer plug in As root, execute the following commands: # rm /usr/lib/browser-plugins/raclass.zip # rm /usr/lib/browser-plugins/rpnp.so Content can still be viewed by starting "realplay" and opening URLs, but automatic exploits via web pages or E-Mails are no longer possible. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SUSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum <name-of-the-file.rpm> after you downloaded the file from a SUSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security(a)suse.de) the checksums show proof of the authenticity of the package. We recommend against subscribing to security lists that cause the e-mail message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig <file.rpm> to verify the signature of the package, where <file.rpm> is the file name of the rpm package that you have downloaded. Of course, package authenticity verification can only target an uninstalled rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SUSE in rpm packages for SUSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SUSE Linux distributions version 7.1 and thereafter install the key "build(a)suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SUSE runs two security mailing lists to which any interested party may subscribe: suse-security(a)suse.com - general/linux/SUSE security discussion. All SUSE security announcements are sent to this list. To subscribe, send an email to <suse-security-subscribe(a)suse.com>. suse-security-announce(a)suse.com - SUSE's announce-only mailing list. Only SUSE's security announcements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe(a)suse.com>. For general information or the frequently asked questions (FAQ) send mail to: <suse-security-info(a)suse.com> or <suse-security-faq(a)suse.com> respectively. ===================================================================== SUSE's security contact is <security(a)suse.com> or <security(a)suse.de>. The <security(a)suse.de> public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SUSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security(a)suse.de> pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GYkAlQMFEDe3O8IWkDf+zvyS FQEBAfkD/3GG5UgJj18UhYmh1gfjIlDcPAeqMwSytEHDENmHC+vlZQ/p0mT9tPiW tp34io54mwr+bLPN8l6B5GJNkbGvH6M+mO7R8Lj4nHL6pyAv3PQr83WyLHcaX7It Klj371/4yzKV6qpz43SGRK4MacLo2rNZ/dNej7lwPCtzCcFYwqkiiEYEEBECAAYF AjoaQqQACgkQx1KqMrDf94ArewCfWnTUDG5gNYkmHG4bYL8fQcizyA4An2eVo/n+ 3J2KRWSOhpAMsnMxtPbBiEYEExECAAYFAkGJG+YACgkQGsiRhDTRlzm8CQCg14Wz vg6j45e/r1oyt9EaHhleSacAnA+2dArk1I3xt49Z5rdnhqheF//9mQGiBDnu9IER BACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff4JctBsgs47tj miI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0dM+HFrruCgBlW t6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcOQliHu8jwRQHx lRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrKXBUX+K7u4ifr ZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBED3+D2t1V/f8l 0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUdG5sRA/9ovnc1 krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NMCC3Kj9aZHfA+ ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoEmyW/xC1sBbDk DUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNrYWdlIFNpZ25p bmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkDwmcABAsKAwQD FQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6dNfnwI2PAsgCg jH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCeQOMQAAqrpNzO AKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNeLZa/qM2JARUD BRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3tXXaJJp9pHMa4 fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBUD9i579uifklL snr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ30kNLWVXWATMn snT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot1ZPtB0lniw+/ xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpWcRgdn2DUVMmp U661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0EExECAB0FAjxq qTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1fAJ9dR7saz2KP NwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0EOe70khAIAISR 0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/HZnh3TwhBIw1 FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44ht5h+6HMBzoFC MAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPTtGzcAi2jVl9h l3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM523AMgpPQtsK m9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q2Y+GqZ+yAvNW jRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8QnSs0wwPg3xE ullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWawJxRLKH6Zjo/F aKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ1sj2xYdB1xO0 ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCHORrNjq9pYWlr xsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1wwylxadmmJaJ HzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQYEQIADAUCOe70 kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol0JdGwACeKTtt geVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAKCRCoTtronIAK yofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3coSPihn1+OBNw= =Fv2n - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQfULuXey5gA9JdPZAQFlBQf/TBBqYIAXgwKUKxq9qOpXOLQQ1L+CkTy+ Ck0FIKtH/YrqmfxIudDPQzzvBBQqM530SohAyQT90kz/9L6nxc3n2RgKdu03pUlt mgmE5sOm9ImEM3ror7j+ZzyWcGCFPyC/4SWtHwzTZi1cgcRZwpuxEhBps2C3LO2k QJdUWHlPTcYJVVnqGvxk2ZGokpiVlvMTzLMXJe+Cq0cZIwMS9lB3x+GHdkYDBRES 1m8mgleJN8jpyJRNRMLyKcqTYHOAllDFuC2rte2AajUcxdX87Uxl6X0sBBWwTtNK c+AeKyMzFm4U/mxbjdfS1UOcGnIRAt1nJ2OqYZ9i8AO30y4ooEwTmw== =j1Cu -----END PGP SIGNATURE-----

1 0

Multiple YOU patches with _seemingly_ outdated versions...
by pelibali 21 Jan '05

21 Jan '05

Hi List! I made a short PERL script, for doing some statistics-analysis on all of the new and obsolete patches available via YOU. But there are several packages, where I can't find out, what is behind, and why I see sometimes seemingly outdated packages. One example xine-ui and xine-lib, where actually both of them were build from xine-lib-xxx.nosrc.rpm, but as the vulnerability was discovered, from TWO different versions: Buildtime: 2004-04-26 16:18:03 Package: xine-ui-0.99.rc3a-106.3.i586.rpm Source: (xine-lib-0.99.rc3a-106.3.nosrc.rpm) Buildtime: 2004-11-16 13:55:32 Package: xine-lib-0.99.rc3a-106.15.i586.rpm Source: (xine-lib-0.99.rc3a-106.15.nosrc.rpm) My question would be (even, that I realized, that there is nothing wrong!), that how is this possible, that after the second patch got available via YOU, the xine-ui-0.99.rc3a-106.15.i586.rpm was not build again from the updated source? Another, more theoretical question would be, that in case one decides to build e.g. the first package from the _newer_ source, would one get the same as the prior variant xine-ui, only with a tiny change exclusively in the version-numbers? (While checking the output of my program, in the case of some arts, dhcp, kdelibs3, subversion, and XFree86 packages the situation is very similar: few updated rpms coming from updated sources, but their 'sisters' got no update...) I'm not so familiar with deeper rpm-related themes, so I would be really hapy to get a correct explanation, more or less on the user-level:) Thanks a lot, Pelibali

3 3