Question about Unspported openSUSE Repositories - Are they secure?

English Applications
#1

When looking for an application that is not in the default opensuse repositories,
I go to software.opensuse.org: Search to get them e.g. fluxbox, keepassx

This warning message is shown before showing the packages:

Please be aware that the following packages are from unofficial repositories. That means they are not reviewed by openSUSE and may contain unstable or experimental software.

I am fine with unstable or experimental software.
However I am curious/concern if these repositories are as secure as the main repositories (since openSUSE declared that they had not reviewed it).

Can we safely assume that these are as secure ?

#2

On 2013-01-31 11:26, michalng wrote:
> I am fine with unstable or experimental software.
> However I am curious/concern if these repositories are as secure as the
> main repositories (since openSUSE declared that they had not reviewed
> it).

There is no way to know.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#3

On 01/31/2013 11:26 AM, michalng wrote:
> Can we safely assume that these are as secure ?

no. they might be a hot-bed of rootkits…

but, to the best of my knowledge nothing like that has ever been found,
reported or even hinted at…

personally, i shy away from the /home accounts (except for those who i
recognize as long time contributors, and therefore trust, like:
<snip>/repositories/home:/malcolmlewis:/<snip> and
<snip>/repositories/home:/please_try_again/<snip>)

–
dd
http://tinyurl.com/DD-Caveat

#4

Yeah. I leave a warning on my obs repository stating that everything here is experimental and will not have any help if it breaks.

#5

Don’t the obs directories and download.opensuse.org get scanned every now an then :slight_smile:

#6

> Don’t the obs directories and download.opensuse.org get scanned every
> now an then :slight_smile:

the official directories are closely monitored and protected by
certificates and hash…

but the /home directories: scanned by what/who?

–
dd

#7

Forgot the question mark in the post. It seems any malware and come and attach itself with packages in download.opensuse.org :frowning:

#8

On 2013-01-31 18:16, nightwishfan wrote:
>
> Yeah. I leave a warning on my obs repository stating that everything
> here is experimental and will not have any help if it breaks.

That’s nice of you. But how can we see that warning when adding a repo
with, for instance, “zypper ar …”? Does it show?

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#9

Breaking is okay, as mentioned previously, there’s a warning message shown before showing the packages:

Please be aware that the following packages are from unofficial repositories. That means they are not reviewed by openSUSE and may contain unstable or experimental software.

My concern is more on security.
Since the officialy message only mentioned breakage, does it implies that the security is okay?

For example, when looking for keepassx, definitely security is important since it holds all passwords for its users.

Using keepassx as an example again:

this repo looks official/safe/secure

Index of /repositories/security:/passwordmanagement/openSUSE_12.2

this repo maybe, depending if we know the user

http://download.opensuse.org/repositories/home:/username/openSUSE_12.2/

But if the search is done through an officialy channel provided by openSUSE (software.opensuse.org: Search),
and the warning is only on breakage and not security,
users like me may assume that the repos presented are secure >:(

#10

It depends on how you define “security”.

  1. There’re three 3 sets of repositories in openSUSE:
  • Official Repositories for User: OSS and NON-OSS
  • User Home Repositories: A user’s own playground starting with home:xxx
  • Official Devel Repositories for Dev: All others.

Server Side: They’re all on the same infrastructure (OBS Server and d.o.o Server) and under the same protection by SuSE (We can’t, eg, just protect an OSS directory and let other stuff on the same server exploded, because such action is harder to achieve and is also a potential threat to our servers.

Client Side: Their packages are all protected by the automatically created GPG keys to prevent man-in-middle attack or transmission loss. That’s why you have to import an GPG key before adding a repository. If something is changed, YaST or zypper will warn you. This is also the common technology used by Distributions to deliver packages, which is, to make the one you get the same as the one on server.

So literally, if you define security as the security in “security service”, All repositories openSUSE provided and the ones openSUSE provided infrastructure only, are under a same level. If there’re ways to attack “unofficial”, “unstable”, “experimental”, “unreviewed” repositories, openSUSE official ones can’t survive either.

  1. If you define “security” as “Don’t deliver malware”.

It hardly can be although it still can. But such action can’t exist long. Because the cracker has to upload source code to build on OBS (we have a blacklist preventing shipping binaries), I don’t know if SuSE have security scan for uploaded sources, but it’s too easy to find such behaviors that no one will actually choose to implement it.

  1. If you define “security” as “Don’t brick my system”.

It can.

home repositories are users’ playgrounds, you don’t know if they are packaging masters or they know nothing. I don’t know either. That’s why we warn you “experimental”.

devel repositories are developers’ playgrounds, we make less mistakes than users, but we still make mistakes, we introduce bugs. Even in Factory there’re also a lot of unknown bugs existing. The procedure from devel repo to factory repo can only eliminate packaging flaws. But as there are more bugs in devel repositories than factory repository, we warn you “unstable”.

Hope it helps

Marguerite

#11

Actually,
IMO package security and system security in the FOSS world leaves a lot to be desired.

Sure, source is open and can be inspected but very few people have the skill and talent to properly evaluate code for outright malware and faultiness leading to vulnerabilities and then exploits.
I also categorize unintentional code flaws as serious as intentional malware which is likely harder to detect than code known to be bad and therefor tagged with a signature.

So, like many other things in life you should educate yourself as much as possible to make reasonable decisions and always be able to recover from minor issues to disasters, plus be aware as much as possible.

On a slight tangent, today the trend is to permit more invasion and loss of information even using legal means by creating common standards that increase functionality (because Users want it) but require granting use of your machine without permission.

But, back to repos… Has been a long-discussed topic on many boards…

  • GPG keys are a relatively new requirement, still not used by everyone and even the current implementation has lots of holes, like…
    -GPG keys does not have a trusted hierarchy which supports true proper Trust at the highest (root) levels except in rare cases like the distro keys pre-installed. There is nothing to compare with for example the x509 CA used for SSL and code-signing (and more).
  • Asking the User to authorize keys for Community repos is subject to well known issues like fooling the User, MITM at that moment, more.

So, all in all it might be remarkable that there hasn’t been a big catastrophe, on the other hand if you trust in the Goodness of people and are careful what you put in your machine then you shouldn’t worry too much. :slight_smile:

But, if you do intend to do something with unusual risk then isolate the environment, like running in a VM.

IMO,
TSU

#12

On 2013-02-01 18:56, tsu2 wrote:

> - GPG keys are a relatively new requirement, still not used by everyone
> and even the current implementation has lots of holes, like…
> -GPG keys does not have a trusted hierarchy which supports true proper
> Trust at the highest (root) levels except in rare cases like the distro
> keys pre-installed. There is nothing to compare with for example the
> x509 CA used for SSL and code-signing (and more).
> - Asking the User to authorize keys for Community repos is subject to
> well known issues like fooling the User, MITM at that moment, more.

Like having a browsable list of GPG keys where you can compare who they
are with what yast proposes you to accept. There is no web of trust, either.

In the past some repos had expired keys, for example. Bugzillas about
these problems were ignored even for weeks.

> So, all in all it might be remarkable that there hasn’t been a big
> catastrophe, on the other hand if you trust in the Goodness of people
> and are careful what you put in your machine then you shouldn’t worry
> too much. :slight_smile:

Indeed. Maybe we are too small a target to be of real interest.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)