search

open-eid / DigiDoc4-Client

DigiDoc4 is an application for digitally signing and encrypting documents; the software includes functionality to manage Estonian ID-card - change pin codes etc.
https://www.id.ee/en/article/install-id-software/
Other
120 stars 42 forks source link

Flatpak support #318

Closed Veske closed 6 years ago

Veske commented 6 years ago

There is a movement happening to support a more sane packaging mechanism for userspace applications.

A brief introduction: http://docs.flatpak.org/en/latest/introduction.html

Would it be possible to have an official Flatpak package for Digidoc client? This would allow you to package once and have users run the application on any Linux distribution that has Flatpak installed. No distro-specific packaging.

I thought maybe I could do it my self but unfortunately I am not too familiar with C++ application packaging. https://gitlab.com/Veske/org.veske.Esteidutil/blob/master/org.ria.Esteidutil.json It will compile until xml-security-c for now.

4nd3r commented 6 years ago

related #261

markus-kullerkup commented 6 years ago

Currently Information Authority does not have plans to address this issue due to nature of Open-EID software arhitecture. Releasing Digidoc client is possible through other mediums such as Applemage, Sncapcraft or in your case Flatpak but necessary plugins for browsers can not be transferred through those services.

Veske commented 6 years ago

At least in my opinion a browser plugin is a completely separate piece of software that should also be handled independently. It does not make sense for one .deb or .rpm to ship with browser plugins. Users should be instructed on installation page to refer to their browsers respective plugin shop.

markus-kullerkup commented 6 years ago

Although Digidoc client is functional without browser plugins installed, are significant components that shouldn't be separated.

Veske commented 6 years ago

It looks like your team has done something similar on MacOS where from the AppStore one can install the DigiDoc client and afterwards the browser plugin has to be fetched separately from the browser of choice. Looks like a very sane approach and it would fit with Flatpak also.

getreu commented 5 years ago

@markus-kullerkup

Although Digidoc client is functional without browser plugins installed, are significant components that shouldn't be separated.

Because "Digidoc client is functional without browser plugins installed" browser plugins should be packaged/shipped independly.

getreu commented 5 years ago

From my point of view the DigiDoc Linux (hence FOSS) support has been neglected recklessly. There is only one distribution left with only 2 versions supported in total. But the common argument that support for more Linux distributions is too expensive is not valid any more: A reasonable remedy to improve this situation at low costs is the Flatpack technology. Today Flatpacks are well supported on every Linux system[^2].

In addition to the DigiDoc Desktop application, the question rises how to distribute the corresponding browser plugin.

Here a statement of RIA:

Currently Information Authority does not have plans to address this issue due to nature of Open-EID software arhitecture. Releasing Digidoc client is possible through other mediums such as Applemage, Sncapcraft or in your case Flatpak but necessary plugins for browsers can not be transferred through those services. [...]

Although Digidoc client is functional without browser plugins installed, are significant components that shouldn\'t be separated.

-- Markus Kullerkup, 5 Sep 2018, Flatpak support, Issue #318, open-eid/DigiDoc4-Client

I disagree with this statement: Internet browsers always have had their proper infrastructure to distribute and install plugins. Is common that a Desktop application needs an additional plugin that has to be installed from the browser\'s plugin repositories (a kind of app-store for browser): For example, the very popular and widespread Zotero software shows that this model works well and is widely accepted. As a result, distributing the DigiDoc Desktop Application as a Flatpack package and the browser plugin through the browswer\'s plugin store would not pose a problem. This is especially true for Linux users who are in general more technical adapt than the average Windows user.

For Estonians the DigiDoc software is crucial because it is indispensable to deal with legal digital signatures. As of 22.04.2019, RIA the only Open Source Desktop operating system that has support for DigiDoc is Ubuntu 16.04 (LTS), 18.04 (LTS) (64bit), 18.10. All other Linux distributions are ruled out which discriminates Open Source technologies in favour of Microsoft.

[^2]:

oskarkook commented 3 years ago

I have managed to package the application as a Flatpak, however there is one remaining issue with the pcscd service integration. Hopefully we can collaborate and figure this out, so the application could be used from non-Debian distributions.

Currently, on startup, I get a UI dialog with the message "Failed to load PKCS#11 module". This seems to be related to the message on terminal:

Loading: "opensc-pkcs11.so"
Failed to resolve symbols

I hope that someone smarter than me can take a bite at the last remaining bit and figure out what is happening there. I have looked at other Flatpak applications that integrate with pcsc and they don't seem to have any magic configuration going on, besides depending on pcsc-lite (as this application does, too). Hopefully there is some simple resolution to this.

oskarkook commented 3 years ago

I have fixed the issues with my Flatpak package. I also created a single-file Flatpak bundle that others can use if they wish: https://github.com/oskarkook/qdigidoc-flatpak/releases/tag/v0.0.1

Veske commented 3 years ago

I have fixed the issues with my Flatpak package. I also created a single-file Flatpak bundle that others can use if they wish: https://github.com/oskarkook/qdigidoc-flatpak/releases/tag/v0.0.1

Would it be reasonable to attempt to publish it in Flathub as well ?

oskarkook commented 3 years ago

Yes, although I'd like to have approval for that from the maintainers of this repository first. And hopefully I get some verification from other users that this works for them before publishing to Flathub, which is kind of the non-official-but-actually-official Flatpak package repository. Don't want to publish anything broken there.

Veske commented 3 years ago

@oskarkook

I lack the smartcard reader these days so I can not tell if the card reader part works for me.

Apart from that: Crypto module seems to work. Can encrypt and decrypt and add various recipients as necessary. Opening signed containers seems to work, showing the signatures and allowing files inside of it to be saved on disk. I did notice that inside of Flatpak, digidoc is unable to automatically open the file with the correct app - only option is to use the blue saving icon and then open it your self via file manager.

Signing seems to not work, getting:

2021-06-04T19:28:41Z D [ASiC_E.cpp:131] - ASiC_E::createInternal(/home/kaspar/Downloads/laks.asice)
RIA.SmartID: SSL Error: "The issuer certificate of a locally looked up certificate could not be found" ("DigiCert SHA2 High Assurance Server CA")
RIA.SmartID: "SSL handshake failed. Check the proxy settings of your computer or software upgrades."

I had the same issue with the RPM packaged Digidoc client some time ago, but this patch https://src.fedoraproject.org/rpms/qdigidoc/c/fcbaae479434a5e7678e9806fcddf2c1b917ab70?branch=rawhide fixed that for me. Seems like they just updated the application it self ?

oskarkook commented 3 years ago

Thanks for trying it out @Veske!

Indeed, signing with SmartID and MobileID was broken. I have released a new version: https://github.com/oskarkook/qdigidoc-flatpak/releases

For my future self and other interested parties, I will describe the problem with the signing.

It seems connecting to https://dd-mid.ria.ee (MobileID) and https://dd-sid.ria.ee (SmartID) failed, presumably because the CA certificate that is used by RIA for those servers was missing in the Flatpak. Normally Flatpak can access the host's certificates through p11-kit (which would solve the issue), but qdigidoc4 uses openssl, which I guess doesn't support p11-kit. I am not an expert on any of this, though, so someone can probably correct me.

Fortunately, the Flatpak build succeeds with org.kde.Platform//5.14, which includes a newer version of Freedesktop, which in turn includes a newer version of ca-certificates. Luckily in 5.14, it's new enough that the necessary CA certificate is in there. The Flatpak does not build with 5.15, but right now it does not seem to be an issue.

oskarkook commented 3 years ago

As for opening the files through the Flatpak, I will check that out sometime, maybe we can fix it. Thanks for reporting that!

Veske commented 3 years ago

Thanks for trying it out @Veske!

Indeed, signing with SmartID and MobileID was broken. I have released a new version: https://github.com/oskarkook/qdigidoc-flatpak/releases

For my future self and other interested parties, I will describe the problem with the signing.

It seems connecting to https://dd-mid.ria.ee (MobileID) and https://dd-sid.ria.ee (SmartID) failed, presumably because the CA certificate that is used by RIA for those servers was missing in the Flatpak. Normally Flatpak can access the host's certificates through p11-kit (which would solve the issue), but qdigidoc4 uses openssl, which I guess doesn't support p11-kit. I am not an expert on any of this, though, so someone can probably correct me.

Fortunately, the Flatpak build succeeds with org.kde.Platform//5.14, which includes a newer version of Freedesktop, which in turn includes a newer version of ca-certificates. Luckily in 5.14, it's new enough that the necessary CA certificate is in there. The Flatpak does not build with 5.15, but right now it does not seem to be an issue.

Tested 0.0.2 out, signing files with Smart-ID worked correctly.

On top of missing ID-card reader I also lack Mobile-ID support currently so I am unable to confirm that right now. Perhaps someone else (@getreu ?) can help with that.

oskarkook commented 3 years ago

I don't have MobileID either.

I also packaged the chrome signing module with the Flatpak. See the readme for more information: https://github.com/oskarkook/qdigidoc-flatpak#extension

Works fine on a fresh installation of Fedora 34.

oskarkook commented 3 years ago

I'm personally fine with pushing this to Flathub.

Funnily enough, we could replicate the functionality of install-open-eid.sh (that is currently distributed through id.ee) with a couple of lines, through Flatpak. The only step that actually needs a script is the native messaging host declaration file, otherwise user could just install the Flatpak on their own and the extension through Firefox/Chrome store and they would work with eachother without any scripting needed.

I wonder if there is any way to place the messaging host declaration file in the needed path without extra steps :thinking:

Veske commented 3 years ago

I tested it with a ID-card reader as well. For me it worked fine. Picture loads, files can be signed etc..

Any way I can help to get it to Flathub ?

oskarkook commented 3 years ago

Thanks for testing :) @Veske.

For Flathub, the requirements are here: https://github.com/flathub/flathub/wiki/App-Requirements

Of these, the licensing is the thing that could need a check-up. If you are interested in that sort of thing, it would be greatly appreciated if you verified whether we can re-distribute the application in its entirety as-is.

There are a couple of files that are downloaded during the build at the moment, for which we also need to check whether we can bundle them in the binary or whether they need to be downloaded at install time. Is it so that since those are probably unlicensed, we would need to mark them under the extra-data field as described in the App Requirements?

I will check what exactly is downloaded. I also need to disable network access during build: https://github.com/oskarkook/qdigidoc-flatpak/issues/3. After that, given that licensing is figured out, we can proceed to Flathub.

oskarkook commented 3 years ago

I prepared the repo to be in compliance with Flathub requirements. However, we can not yet push to Flathub, as we don't meet the following criteria:

All of these need a confirmation from the project owners, preferrably it would even be them who finalize the submission. If anyone is interested in chasing the responsible persons down, that would be appreciated.

Veske commented 3 years ago

@markus-kullerkup @kristelmerilain Do you have any feedback to leave for the comment above ?

asinitson commented 3 years ago

Confirming that package from @oskarkook (nice work!) functions well in openSUSE 15.2 (I tested only signing with Smart ID, not anything else). Before that I tried some user maintained repository and they had issues with certificates. Here is how to do it (I tested it under KDE):

VERSION=v0.0.5
wget https://github.com/oskarkook/qdigidoc-flatpak/releases/download/${VERSION}/qdigidoc4.flatpak

# Root password dialogs will popup several times during installation.
# Dependencies will be fetched automatically from `flathub` remote repository.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install qdigidoc4.flatpak

flatpak run ee.ria.qdigidoc4

P.S. Dependencies are quite big. Not sure if it is easily fixable (>1300MB, while qdigidoc itself is <68MB):

flatpak list --columns=ref,size
Ref                                                                       Installed size
ee.ria.qdigidoc4/x86_64/master                                             67.5 MB
org.freedesktop.Platform.GL.default/x86_64/20.08                          313.1 MB
org.freedesktop.Platform.GL.nvidia-470-57-02/x86_64/1.4                   984.1 kB
org.freedesktop.Platform.openh264/x86_64/2.0                              778.2 kB
org.gtk.Gtk3theme.Breeze/x86_64/3.22                                        3.9 MB
org.kde.Platform/x86_64/5.15                                                1.0 GB
oskarkook commented 3 years ago

Thanks for the feedback @asinitson and I'm glad it works for you!

If we can't push to Flathub, I am considering creating a separate Flatpak repository to distribute it. This way it could auto-update. Builds would be done with Github Actions to ensure a safe build environment.

asinitson commented 3 years ago

@oskarkook: That would be great! I also have some card readers lying around and I have access to an Ubuntu 18.04 machine (besides openSUSE 15.2-soon-to-be-15.3), so if you need some help with testing, I will be glad to do it.

oskarkook commented 3 years ago

https://github.com/open-eid/DigiDoc4-Client/issues/793#issuecomment-920050767

I also received an e-mail about this, so luckily there might be a more official push for this. I did not receive approval for a Flathub release, though. I will just try to keep my repo up to date until then.

MysteriousNothing commented 2 years ago

@oskarkook Doing what Estonian official developers can't for years. Good Job!