openSUSE Security

Download

security@lists.opensuse.org

December 2013

3 participants
2 discussions

[opensuse-security] Why is esound-daemon automatically installed on opensuse 12.3 when using zypper dup?
by Joop Boonen 27 Dec '13

27 Dec '13

Dear all, Today I did a sudo zypper dup. I saw: sudo zypper dup root's password: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Retrieving repository 'openSUSE-12.3-Update' metadata ................................................................................[done] Building repository 'openSUSE-12.3-Update' cache .....................................................................................[done] Loading repository data... Reading installed packages... Computing distribution upgrade... The following NEW package is going to be installed: esound-daemon The following packages are going to be upgraded: As I wondered why esound-daemon was installed I've checked out what package needs this package: rpm -q --whatrequires esound-daemon no package requires esound-daemon I've deleted this package via: rpm -evh esound-daemon Preparing... ################################# [100%] Cleaning up / removing... 1:esound-daemon-0.2.41-23.1.1 ################################# [100%] without any problems. I wonder why esound-daemon is automatically installed? Regards, Joop. -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 2

[opensuse-security] Re: [review-team] Submission with changed .keyring
by Sascha Peilicke 18 Dec '13

18 Dec '13

On Wednesday 13 November 2013 10:14:48 Dominique Leuenberger a.k.a. Dimstar wrote: > Quoting Michal Vyskocil <mvyskocil(a)suse.cz>: > > Hi all, > > > > in order to get back to the work, I would like to point your attention > > to https://build.opensuse.org/request/show/206502 > > > > Tomcat got new release manager, which means changed tomcat.keyring. As > > there is no policy how to do that, I've made my best. So tomcat.keyring > > does use only new key and it is mentioned in .changes including new key > > and a linked to svn commit adds the new id to tomcat7/KEYS file. > > > > Is there anything else you'd like to mention? > > Michal, > > I'd seen that request and I really appreciate the way it's documented. > It shows that there has been clear thought and not 'just replacing' > the .keyring. > > Replacing the .keyring MUST be a sensible topic for the review team > (if not: we can as well remove the logic: if injecting a random > keyring into the package does not result in the verification of the > keyring, it's wasted space). I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained. Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that. We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package. Net result, one less review task that was spoiled since it's inception anyway. CC'ed the sec guys therefore... > I did not yet have time to actually do the KR validation.. but from a > .changes entry, I think it's just right. As said, I can certainly live with mentioning it. Maybe it's even a good idea. It's just not helping anybody ATM. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

3 4