search

keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
900 stars 37 forks source link

need installation procedure (documented) for openSUSE #2569

Open aspiers opened 8 years ago

aspiers commented 8 years ago

Hi there! keybase is awesome! :-) But https://keybase.io/docs/the_app/install_linux does not provide an installation procedure for openSUSE :-( And #2445 suggests that installation of the Fedora rpm has not been tested on openSUSE.

As an active developer / packager / maintainer within the openSUSE community, I would like to offer to help to fix this. The most effective way to distribute keybase on openSUSE would be to build it in the Open Build Service; in fact we already did this for keybase-node-client in the past. (In fact you could even use OBS to build and distribute packages for many other Linux distributions too ...)

But I am open to all avenues of distribution. Please can you let me know how I can help with this? Many thanks!

aspiers commented 8 years ago

/cc @restena-sw @bmwiedemann @abonillasuse

cjb commented 8 years ago

Hi Adam, have you tried installing our RPM on OpenSuSE? Would be curious to find out what the problems are, if any, in case they are easy fixes.

(In general I don't think we find build services attractive -- we're still early in development and releasing a new package every day, and we like to be distributing e.g. using our own signing keys instead of a distro's.)

aspiers commented 8 years ago

Hi Chris, thanks for the quick reply. Yes I have tried it, and I found the same problem as in #2445. Other than that it seems to work OK, although I suspect rpmlint might pick up a few minor issues as it usually does.

Releasing a new package every day is actually a strong argument for using OBS, not against it ;-) That's because it automates a huge amount of the build process, even to the extent of automatically retrieving upstream tarballs, validating their integrity using checksums or PGP keys, or automatically building tarballs from an upstream repository, automatically updating the .spec file to the new version, automatically updating the change log etc.

Here's some further reading in case you are interested:

I admit that the documentation still needs improving in places, but I'd be happy to help fill in the gaps (and there's also a very helpful community on the FreeNode #opensuse-buildservice channel and mailing list).

aspiers commented 8 years ago

BTW to correct a very common misunderstanding about the capitalization of the project - it's "openSUSE" ;-) The weird "SuSE" capitalization was dropped back in 2004 or so, before openSUSE was launched.

aspiers commented 7 years ago

Hi @cjb, any more thoughts on this? The offer to help still stands.

cjb commented 7 years ago

@aspiers Hi! Let's see if the RPM fix PR works -- if so, I think we'd be happiest just continuing to ship RPMs. In general I think we have the type of paranoia that involves wanting to build, sign and distribute our binaries ourselves, so adding an extra (and seemingly unnecessary) indirection via OBS doesn't feel attractive at the moment.

aspiers commented 7 years ago

Thanks for the reply! Well, I wouldn't call it unnecessary - there are several practical advantages to building OBS. But I understand your point about paranoia; certainly keybase is a special case in that regard since trust in it is paramount to its success.

It might be worth thinking in more detail about exactly what threats are making you paranoid in this context, though :-)

Threat 1: trojan code inserted into sources

The integrity of the sources are no less trustable or verifiable if they are hosted in OBS vs. your servers, since you can still sign them with your own keys, and users can easily verify those signatures in both cases.

Threat 2: security of package building process is compromised

From a user's point of view, I'm not sure that there's anything inherently more trustable about the process of building packages from these sources whether it's done by you vs. OBS. Keybase as a vendor has (AFAIK) an excellent reputation, but so does openSUSE, and the OBS has been around for a very long time now.

I would expect that the integrity of the package building process is more verifiable when done in OBS than by keybase, since the OBS package-building process is very transparent:

  1. the inputs for each build and the resulting build log are always visible, and
  2. the build can be locally reproduced via a single osc command and the (mostly deterministic) results can be compared byte-for-byte with the server-side build

ICBW but I'm guessing that these two points do not hold regarding the keybase package building process, which means that as a paranoid user I'd be slightly less inclined to trust packages from keybase than from OBS.

Threat 3: honest mistake in packaging building process

We're all human, and it's easy to get a .spec file wrong which might lead to some incorrect file permissions or other security issue. On OBS, all the build inputs are available for peer review, anyone can improve them, and when they get submitted into the distribution they go through fairly strict QA which can catch a lot of mistakes (and in the SUSE world we've been doing this stuff for ~25 years so we've gotten quite good at it by now ;-). Again these advantages do not exist if keybase builds the packages.

I'm sure there are other advantages of building in OBS that I've missed, but equally I've probably missed some advantages of maintaining the status quo, and ultimately I expect you guys are more expert in security than I am ;-) But I hope this is valuable food for thought at least ...

adrianschroeter commented 7 years ago

The important point is that the build process is reproducible and the build results can be compared. This is true for any way of building, no matter of individual builds or in some service. OBS has some value here, but you might be able to achieve this also with your own builds.

The value of OBS is in first place when you need to take build dependencies into account, means other packages influence the result of your package. Also when you want to build for multiple distros at once, having automated CI builds or when you want to collaborate with others on package building.

Use OBS only if that is appealing to you;)

LenzGr commented 7 years ago

I also would like to highlight the possibility to build packages (not just RPMs, but DEBs, too) for multiple distributions from a single source archive as a key highlight of OBS. It's not SUSE-specific.

bmwiedemann commented 7 years ago

https://lists.opensuse.org/opensuse-factory/2017-04/msg00109.html also has information on which 3 rpm macros to set in your OBS project config to get bit-identical rpms out of it.

aspiers commented 7 years ago

(In general I don't think we find build services attractive -- we're still early in development and releasing a new package every day, and we like to be distributing e.g. using our own signing keys instead of a distro's.)

Other options worth considering: release a Flatpak image or an AppImage (type 2 images can be GPG-signed) or a Snapcraft snap. These package delivery mechanisms offer the kind of control and independence you seem to want. The downside of these approaches is that they shift the responsibility of dependency management from the distro to the application packager, so you risk duplicating effort already taken care of by distro package building services such as OBS. (BTW, it is possible to build AppImages and snaps in OBS too ...)

aspiers commented 7 years ago

Hi again @cjb, any more thoughts on the additional information I and some other openSUSE folks shared here? :-) Thanks!

cjb commented 7 years ago

@aspiers Hi again! We use a FUSE filesystem (for /keybase) and I'm not sure whether that's possible in Flatpak or AppImage or Snapcraft. If anyone has any info on that, would be happy to hear it. We'd need root access to create the /keybase dir, even if it's not needed to perform the actual FUSE mount.

Hm, we could consider not installing /keybase by default and asking to elevate privileges if the user wants to use it. That's something we do on other platforms. I'm not sure whether Flatpak etc allows you to request root privileges at runtime either, though. The whole point seems to be to have filesystem sandboxes for applications, whereas the point of this aspect of Keybase is to provide a global filesystem. :)

(Unrelated, but for what it's worth, keybase/keybase-issues#2987 was kind of a bummer -- it felt like the Zypper bug presented an attitude of thinking that people hosting RPMs must make somewhat-arbitrary changes just for openSUSE's convenience, which seems unrealistic and unproductive. I wonder how that bug ended up.)

So I think that's where we are -- all of these new app bundle formats look promising but don't seem to be a great match for our root-needing filesystem app. Thinking about it, if we didn't have any build system then I can see us considering OBS, although I'm not sure which side of the security-of-package-building-process argument we'd end up on. But we already have our own build system, and a lot of work to do with a small team, so I think it's unlikely we'd find a move attractive enough to go for it.

I'm happy to leave this issue open, though. If there's any progress in app bundling that would make Keybase a good fit for it, I think we'd be interested in distributing one, and would reconsider how best to build it.