Home_greyopenFATE - openSUSE feature tracking > #306192
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Make BuildService accessible for anonymous users

Feature state



We hides many useful information about our distribution behind a Novell login,
which makes a participation harder. Other distributions are much more opened
even for anonymous users, so you can browse source codes, patches, changelogs,
build logs, ... even if you are an anonymous users. We should be opened as much
as possible if we want to be a community based distribution.

Some examples:

  • Fedora CVS expose all
    Fedora packages with full history and for anonymous users
  • kojibuild info - you have a full access to building informations from koji
    system and some of them are not available for OBS users at all.
  • Debian changelog browsing Debian offers a changelog browsing (they don't use a centralized VCS) without registration.
  • lintian reports you can see a lintian issues for every package.
  • Debian build log Debian also offers an access to a build log of package.
  • Gentoo package information Gentoo offers many information about package

Those examples are only for illustrate of other approaches. I don't try to
tell we must implement CVS because Fedora has it. And some issues like an
alternative of Gentoo package view should be implemented in upcoming Software

We should publish (at least for openSUSE:* projects) sources of packages and a build logs.


With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines.

With no login for read access, we can implement a Fedora mock-like build at the user's machine.


icons/user_comment.png A. J. wrote: (9 years ago)

I would mark this as mandatory moving forward.

icons/user_comment.png S. K. wrote: (9 years ago)

The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam.

Besides that it would be a nice addition.

icons/user_comment.png J. W. wrote: (9 years ago)

Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here.

Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed.

icons/user_comment.png J. W. wrote: (9 years ago)

See also Fate #306381

icons/user_comment.png A. S. wrote: (8 years ago)

Yes, please read #306381 for important implementation details.

icons/user_comment.png A. S. wrote: (8 years ago)

This is it: The OBS Web Client shall offer a read only mode for not logged in users.


  • The current projects and packages shall become browseable
  • Search engines shall be able to index our content
  • Our sources, including the patches should be accessable.
  • Log files shall be accessable for developers without login.

What should not be accessable: Of course no write operations and everything which is causing too much load on our servers. The system must be still usable for packagers as higher goal. This means:

  • No build result downloads via api
  • No monitor pages due to the cause load ?

icons/user_comment.png S. K. wrote: (9 years ago)

Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame-storming sessions.  The system as presently structured promotes collegiality which can help undergird community.

icons/user_comment.png J. W. wrote: (9 years ago)

The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream.

Let us asks Michal Vyskocil if he really wanted to request read+write access without login.

icons/user_comment.png P. P. wrote: (9 years ago)

Making sources easily accessible instead of hiding them
helps productivity immensely. Note that it also helps users
with an account. It is faster and more efficient to access content if you don't need to login first, because often you
are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.)

And you want to foster collaboration with
other communities as well, not only within a "closed" community.

icons/user_comment.png P. P. wrote: (9 years ago)

Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code:
It is very, very hard and costs lots of time.
I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible.

icons/user_comment.png P. P. wrote: (9 years ago)

Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread: 
[opensuse-buildservice] Extreme waste of space by source RPMs  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure.

icons/user_comment.png J. W. wrote: (9 years ago)

Peter, I'd like to invite you to https://fate.novell.com/306656

icons/user_comment.png K. K. wrote: (9 years ago)

any update on this?

There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem.

icons/user_comment.png A. S. wrote: (9 years ago)

This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again).

icons/user_comment.png M. L. wrote: (9 years ago)

Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it?

icons/user_comment.png A. S. wrote: (9 years ago)

I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan.

(It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster)

icons/user_comment.png A. S. wrote: (8 years ago)

Currently driven by the openSUSE Booster team. important for our next (2.0) OBS release.

icons/user_comment.png M. M. wrote: (8 years ago)

This all should be seen in conjunction with the proposal for ACL: http://en.opensuse.org/Build_Service/Concepts/AccessControl

icons/user_comment.png J. W. wrote: (8 years ago)

No changes are visible on software.opensuse.org,
when do we expect deployment?

icons/user_comment.png A. S. wrote: (8 years ago)

Erm, what do you exepect on software.o.o to happen ?

This will happen on build.o.o when we release 2.0 to it (planned in June)

icons/user_comment.png J. W. wrote: (8 years ago)

Thanks for the timeline.

On the results page of software.opensuse.org/search we have links called 'Go to OBS Project' pointing to https://build.opensuse.org/project/show?project= ...

Currently strangers are blocked with this message:
Please login to access the requested page.

I'd expect to see anonymous access as an alternative here.

Last change: 8 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint