openssh
Build of OpenSSH with Kerberos support
Category:
Application versions:
| Attachment | Size | Date |
|---|---|---|
 openssh-8.1p1-1.armv7hl.rpm | 654.75 KB | 27/10/2019 - 13:56 |
| openssh-clients-8.1p1-1.armv7hl.rpm | 1.27 MB | 27/10/2019 - 13:56 |
| openssh-clients-doc-8.1p1-1.armv7hl.rpm | 59.74 KB | 27/10/2019 - 13:56 |
| openssh-server-8.1p1-1.armv7hl.rpm | 910.42 KB | 27/10/2019 - 13:56 |
| openssh-server-doc-8.1p1-1.armv7hl.rpm | 36.74 KB | 27/10/2019 - 13:56 |
Changelog:
- sshd config can be different on each installation. Command line parameters
are taken from environment file /etc/ssh/ssh-env.conf
Fixes MER#681
Comments
ade
Fri, 2019/11/01 - 11:28
Permalink
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 (https://openrepos.net/users/llelectronicsdev for example), not to enforce it upon users.
lachs0r
Fri, 2019/11/01 - 11:33
Permalink
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
Fri, 2019/11/01 - 11:44
Permalink
There is no such thing as a dist-upgrade on SFOS. The highest version gets installed, regardless of the repository source.
lachs0r
Fri, 2019/11/01 - 11:45
Permalink
That’s not how libzypp works.
ade
Fri, 2019/11/01 - 11:51
Permalink
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
Fri, 2019/11/01 - 11:54
Permalink
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
Fri, 2019/11/01 - 12:10
Permalink
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
Fri, 2019/11/01 - 12:16
Permalink
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
Sat, 2019/11/30 - 00:53
Permalink
@lachs0r, please reconsider this, because (as @ade pointed out) you are creating a fundamental issue for the users of your repository.
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.
See obexd-contentfilter-off's spec file for a bit more detail.
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".
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
Fri, 2019/11/01 - 22:59
Permalink
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
Sat, 2019/11/02 - 01:43
Permalink
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
Sat, 2019/11/02 - 02:05
Permalink
+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
Sat, 2019/11/02 - 06:53
Permalink
Fine. I’ll move this somewhere else.
In any case, I consider openrepos deeply flawed, and it’s very unfortunate that build.sailfishos.org 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
Mon, 2021/11/15 - 20:10
Permalink
> 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
Sat, 2019/11/02 - 18:02
Permalink
You seem to be quick in jumping at conclusions.
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 https://bugs.merproject.org/ (https://bugs.sailfishos.org/ 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 https://sailfishos.org/wiki/SailfishOS , specifically the section "Development services", which is worth reading.
Only suppressing all community contributions, IMO.