- openSUSE Security

[opensuse-security] Re: openSUSE-RU-2017:0342-1: Recommended update for opera
by Armin Rauthe-Schoech 05 Feb '17

05 Feb '17

Hi, I'm running OpenSuSE Leap 42.1 x86_64 and did not get offered the Opera update from this announcement. I was expecting to get it from the "non-oss" update repository: https://download.opensuse.org/update/leap/42.1/non-oss/x86_64/ But the latest version in the above folder is opera-42.0.2393.94 Do I have to enable a different repository to get the latest version 42.0.2393.517 ? The zypper command returns "No provider found": armins1:~ # zypper in -t patch openSUSE-2017-182=1 Loading repository data... Reading installed packages... 'openSUSE-2017-182=1' not found in package names. Trying capabilities. No provider of 'openSUSE-2017-182=1' found. Resolving package dependencies... Nothing to do. Thanks for your help and best regards, Armin On Tue, 31 Jan 2017, maintenance(a)opensuse.org wrote: > Date: Tue, 31 Jan 2017 17:10:41 > From: maintenance(a)opensuse.org > To: opensuse-updates(a)opensuse.org > Subject: openSUSE-RU-2017:0342-1: Recommended update for opera > > openSUSE Recommended Update: Recommended update for opera > ______________________________________________________________________________ > > Announcement ID: openSUSE-RU-2017:0342-1 > Rating: low > References: > Affected Products: > openSUSE Leap 42.2:NonFree > openSUSE Leap 42.1:NonFree > ______________________________________________________________________________ > > An update that has 0 recommended fixes can now be installed. > > Description: > > This update for Opera fixes the following issues: > > - Update to version 42.0.2393.517: > - Wrong anchor to currency converter help link > - LocationConfiguration retry timer can target wrong object > - Currency converter not recognising decimal separator correctly > > > Patch Instructions: > > To install this openSUSE Recommended Update use YaST online_update. > Alternatively you can run the command listed for your product: > > - openSUSE Leap 42.2:NonFree: > > zypper in -t patch openSUSE-2017-182=1 > > - openSUSE Leap 42.1:NonFree: > > zypper in -t patch openSUSE-2017-182=1 > > To bring your system up-to-date, use "zypper patch". > > > Package List: > > - openSUSE Leap 42.2:NonFree (x86_64): > > opera-42.0.2393.517-18.1 > > - openSUSE Leap 42.1:NonFree (x86_64): > > opera-42.0.2393.517-55.1 > > > References: > > > -- 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] https enablement of download.opensuse.org
by Marcus Meissner 30 Jan '17

30 Jan '17

Hi folks, We are currently betatesting a security improvement on our download repositories. As you probably know http://download.opensuse.org/ is our main download redirector for openSUSE both the distribution and the buildservice, that redirects requests to the mirrors that host openSUSE repositories. How are those secured? If a YUM repositories is added to your machine, the imported GPG key it is signed with will ensure the trust of those repositories and imported into your RPM database. This GPG key signs the repomd.xml file with YUM, and the YUM XML metadata in turn chains together SHA256 hashes for all the metadata and packages in the repository. openSUSE already imports the GPG key for the base distribution repositories and update repositories during installation of the system. The various home and other project repositories however only get added later and as they have different GPG keys the verification of those is a challenge. The import of those keys so far was unsafe, as you could only check the GPG key by directly accessing them via the open buildservice, with e.g.: "osc signkey Emulators" Starting last week, the download.opensuse.org redirector now also supports "https", relying on the SSL Root CA infrastructure for some added safety. We are phasing this in slowly as we have concerns about load of the download.opensuse.org machine. So. If you want to try, you can replace the http://download.opensuse.org/ URLs by https://download.opensuse.org/ in the repositories. In the near future software.opensuse.org will follow and also deliver https URLs. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0

[opensuse-security] download.opensuse.org vs software.opensuse.org
by Malte Gell 20 Dec '16

20 Dec '16

Hi there, why does software.opensuse.org enjoy SSL, while download.opensuse.org doesn´t? best regards M -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

9 15

Re: [opensuse-security] don't follow the https'ers off the cliff... ;-)
by L A Walsh 19 Dec '16

19 Dec '16

Jean-Christophe Baptiste wrote: > Are you jocking? > Dowloading an operating system not a sensitive operation? > Software integrity, useless? > > Of course, there are, I need a proof that what I get has not been tampered. ---- You already have it. You have signatures on the rpms. That's what they are for. Https was intended to provide protection from snooping. If you don't think large corporate ISP's can't purchase root-certs, or more likely "subordinated root certs" (those have already happened and only made public when the corps mis-handled the certs and let them get swiped), you'd be naive. On smaller scales, sites with multiple users/clients are already likely to force internal clients to use a caching & filtering proxy to access the outside web. With that in place, they can install site-local root certs on site-owned clients and require mobile clients (if allowed), to install site-local root-certs in order to have access to the outside web. The large uptick in https usage has forced sites not using MITM proxies to change policies. Fortunately, both downloaded rpms and sites providing sensitive tars provide signatures for both that provide tampering protection. Not only do the sigs provide tamper protection during transit, but they also provide tamper protection for rpms stored locally, months later. > Client side, what browser would be caching a 700MB file anyway? It would > serve no purpose. ---- It does. I've fetched 700+ MB images from opensuse and MS from cache as long as 1-2 months after original download. Seeing large downloads complete at >100MB/s is a noticeable event. Wherever possible, I disable individual client and machine caches because they waste space. Instead, I use one large cache on an opensuse machine. Best speed boosts are on interactive websites, where there is more content duplication. It's not common to find 700MB requests duplicated, but given the long time that distro-images stay constant and the size of proxy cache, its happened a few times. Regardless of the transport protocol, the integrity of the downloaded images is still available by signature verification. -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 2

[opensuse-security] Linux Kernel Vulnerabliltiy and OpenSuSE 13.2
by Robert Sichler 02 Nov '16

02 Nov '16

Should I expect a patch for OpenSUSE 13.2 (x86_64) to address the Linux kernel vulnerability known as Dirty COW (CVE-2016-5195)? Or is there another direction I should turn? Best regards, -Bob ________________________________ Notice: This communication, including attachments, may contain confidential or proprietary information to be conveyed solely for the intended recipient(s). If you are not the intended recipient, or if you otherwise received this message in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments, without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is strictly prohibited and may be unlawful. -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 5

[opensuse-security] Re: [security-announce] openSUSE-SU-2016:2386-1: important: Security update for MozillaFirefox, mozilla-nss
by Carlos E. R. 19 Oct '16

19 Oct '16

On 2016-09-26 18:10, opensuse-security(a)opensuse.org wrote: > openSUSE Security Update: Security update for MozillaFirefox, mozilla-nss > ______________________________________________________________________________ > > Announcement ID: openSUSE-SU-2016:2386-1 > Rating: important > References: #999701 > Cross-References: CVE-2016-2827 CVE-2016-5256 CVE-2016-5257 > CVE-2016-5270 CVE-2016-5271 CVE-2016-5272 > CVE-2016-5273 CVE-2016-5274 CVE-2016-5275 > CVE-2016-5276 CVE-2016-5277 CVE-2016-5278 > CVE-2016-5279 CVE-2016-5280 CVE-2016-5281 > CVE-2016-5282 CVE-2016-5283 CVE-2016-5284 > > Affected Products: > openSUSE 13.1 > ______________________________________________________________________________ > > An update that fixes 18 vulnerabilities is now available. I get an error Box: +++................. An error occurred while loading or saving configuration information for [Firefox|thunderbird-bin]. Some of your configuration settings may not work properly. Details: Configuration server couldn't be contacted: D-BUS error: The GConf daemon is currently shutting down. Configuration server couldn't be contacted: D-BUS error: The GConf daemon is currently shutting down. Configuration server couldn't be contacted: D-BUS error: The GConf daemon is currently shutting down. Configuration server couldn't be contacted: D-BUS error: The GConf daemon is currently shutting down. .................++- The daemon is and was running. FF also says: +++....................... Firefox is not currently set as your default browser. Would you like to make it your default browser? [V] Always perform this check when starting Firefox .......................++- Saying Yes does not work, it asks again the next time. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

3 5

[opensuse-security] FYI AppArmor abstraction for AMD proprietary driver
by Malte Gell 10 Oct '16

10 Oct '16

This is an abstraction for those folks who prefer to use the proprietary AMD driver It needs to be added to every profile for X11 apps. It may be more convenient to copy the whole rule into abstractions/x to avoid changing existing profiles. To be honest, this is, what I did when I used fglrx.

2 3

[opensuse-security] RPM signature verification
by Malte Gell 06 Oct '16

06 Oct '16

Hi there, does RPM need to run gpg to verify signatures or is this hardcoded directly into RPM? What is the default behaviour of rpm if signature verification fails for whatever reason, does rpm abort installation of the package? thanx -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 5

Re: [opensuse-security] why no kernel randomization
by Malte Gell 16 Sep '16

16 Sep '16

Am 15.09.2016 um 08:41 schrieb jsegitz(a)suse.de: > On Tue, Sep 13, 2016 at 07:17:34AM +0200, Malte Gell wrote: >> why is the SUSE kernel built without CONFIG_RANDOMIZE_BASE? > > Have a look at > http://bugzilla.suse.com/show_bug.cgi?id=998554 > we enabled it in Tumbleweed, so we can test it there. Thanx, great! I may test it with the Leap 42.1 kernel later this day/week. Best regards -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 1

[opensuse-security] FYI AppArmor Firefox profile
by Malte Gell 13 Sep '16

13 Sep '16

Confining Firefox may be the most important thing you can do to improve security on a desktop system.... As a basis I took some old profile from Ubuntu and added more permissions to make it work. This profile works very well. But it separates Thunderbird, you cannot open mailto links with it. But in my mind, it is better to keep the data of both apps separated. To avoid an attacker steal your email account data and vice very. Both, Firefox and Thunderbird want to load kernel modules. I never looked, what kernel modules Firefox or TB need to load. To me it´s a bit scary to allow them loading kernel modules. I haven´t investigated this yet. In this profile I allowed to access /sbin/modprobe. The profile works with Leap 42.1 and its current Firefox.

1 0