Your rating: None Average: 4 (4 votes)

Build of OpenSSH with Kerberos support

Application versions: 
File openssh-8.1p1-1.armv7hl.rpm654.75 KB27/10/2019 - 13:56
File openssh-clients-8.1p1-1.armv7hl.rpm1.27 MB27/10/2019 - 13:56
File openssh-clients-doc-8.1p1-1.armv7hl.rpm59.74 KB27/10/2019 - 13:56
File openssh-server-8.1p1-1.armv7hl.rpm910.42 KB27/10/2019 - 13:56
File openssh-server-doc-8.1p1-1.armv7hl.rpm36.74 KB27/10/2019 - 13:56

- sshd config can be different on each installation. Command line parameters
are taken from environment file /etc/ssh/ssh-env.conf
Fixes MER#681


ade's picture

I am not sure it is wise to put default system packages in a repo with other apps. It means people will get this openssh version installed once they activate your repo, if they intended so or not. Most developers create a separate repo for this kind of system stuff ( for example), not to enforce it upon users.

lachs0r's picture

That is a tooling problem. The repository manager (or the user in case of zypper) should ensure that addon repos get a lower priority than the system repositories.

And unless someone explicitly does a dist-upgrade with vendor changes allowed, it’s unlikely for openssh to get picked up automatically. I do wonder if enabling developer mode on SFOS will actually replace the package with the SFOS package, or if it just keeps the installed one, or if it installs this version instead of explicitly using SFOS repositories…

ade's picture

There is no such thing as a dist-upgrade on SFOS. The highest version gets installed, regardless of the repository source.

lachs0r's picture

That’s not how libzypp works.

ade's picture

I can tell you from past experience that that is how SFOS works in practice. OpenSuse (also based on libzypp) asks you to change vendor first. SFOS does not.

lachs0r's picture

Only in case of zypper dup, which should never be used without --no-allow-vendor-change (the default in openSUSE’s zypp.conf).

For regular updates (zypper up), it should not just change vendors, and package installs follow the repo priority setting.

ade's picture

Again, I am just saying how pkcon behaves on SFOS and how I got my systemd replaced once because someone place a personal version in his repo. It's fine if you don't want to test it and stick to how a default libzypp implementation should act in theory. My warning still stands.

lachs0r's picture

If storeman or whatever people use to manage openrepos adds user repositories with the same or higher priority than the system repos (which actually seems to be the case!), that’s definitely a very serious bug that needs to be addressed. That’d be the only correct way to go about this issue.

If a malicious user (or hacked account) is able to replace random system packages, that is a problem.

olf's picture

@lachs0r, please reconsider this, because (as @ade pointed out) you are creating a fundamental issue for the users of your repository.

  • The GUI app managers Storeman and Warehouse will offer any package, which supersedes an installed (system) package, as an update. It is up to the user to install it (or not), but an "Update all" sure will. Hence many users will end up installing such packages without realising it.
    You may blame that on many users' lack of understanding or the app managers, but IMO this is not a responsible approach as a package / repository maintainer.
  • When performing an SailfishOS upgrade, it carries out a dist-upgrade (or equivalent, see cat /usr/bin/version), which will automatically install packages from enabled repositories which supersede system packages.
    See obexd-contentfilter-off's spec file for a bit more detail.
  • It is necessary and normal for Linux distributions to let third party repositories replace system packages, otherwise e.g. QtWebkit 5.212 DEV, Bluetooth OBEX Filter off and many other packages would not be easily installable at the GUI (only).
    It is solely the user's responsibility, whom to trust by enabling one's repository (as it is with other Linux distributions, e.g. Ubuntu), as there is no explicit "vendor repo override flag".
  • Four years ago issues with repositories set up like yours became so imminent (a couple of people broke their SailfishOS installations when upgrading the OS, for which Jolla was accused), that they released an "official" warning to disable all OpenRepos' repositories (calling out a real life example) before upgrading, also at Jolla's Zendesk plus explicitly mentioning this in their release notes (and also before).
    While this has been alleviated in SailfishOS 1.0.4, hence the radical measure of disabling all OpenRepos' repositories is not necessary anymore, issues with repositories offering system package replacements still arise occasionally due to not being handled properly by their maintainers (e.g. in a package's spec file or by not putting it into a separate repository).

tl;dr: You might not want doom your users.

lachs0r's picture

All of these can be fixed by making storeman set up repo priorities the way it’s supposed to. The way it is now, with arbitrary user repos overriding system repos *BY DEFAULT* and also allowing vendor changes, is absolutely broken.

This is just like in the old days of openSUSE Factory where people would routinely break their systems by using devel repos without assigning priorities. Whether or not there are repos like mine, this is just asking for trouble.

olf's picture

Well, then go for that, by contributing to or forking Storeman.

Until that is working and widely deployed, you really better put packages, which substitute system packages, in separate repositories.

szopin's picture

+1 People had their devices broken before due to this during system updates, it's much easier to complain about how openrepos/storeman behaves/should behave than actually implementing a proper fix, until then you really shouldn't include base system packages in a repo where you also ship your random apps

lachs0r's picture

Fine. I’ll move this somewhere else.

In any case, I consider openrepos deeply flawed, and it’s very unfortunate that is currently broken and not open signup, and that setting up a project hierarchy like openSUSE Tumbleweed’s to build a proper community-managed store with an actual review process has never been considered.

I run an OBS instance on my own server and would be more than willing to try getting something like this off the ground, but I cannot even get the interconnect to work, and so far I’ve been getting exactly 0 support.

olf's picture

> Fine. I’ll move this somewhere else.

"Ping", i.e.: Please do it.

> In any case, I consider openrepos deeply flawed, [...]

It is Jolla which disables repository priorities and does not allow for "--no-vendor-change", IMO because ssu cannot handle them.
AFAICS there is nothing Openrepos or Storeman can do about that.
If you file a bug at FSO, I will sure support you.

olf's picture

[...] and it’s very unfortunate that is currently broken and not open signup, and [...] an actual review process has never been considered.

You seem to be quick in jumping at conclusions.

  1. Jolla is currently migrating from to
    On both front-pages it is clearly stated:
    To login to this build service you'll need to contact lbt on irc in #sailfishos on freenode and get him to register you on the Community Bugzilla
    A bit more detail is provided at ( apparently is not ready, yet). It was easy for me to obtain an account by sending an request per email (years ago), as denoted there.
    The big picture (and more) is concisely documented at , specifically the section "Development services", which is worth reading.
  2. What is the effect of a review process with no reviewers?
    Only suppressing all community contributions, IMO.