hw42 / qubes-app-linux-split-gpg2 Goto Github PK
View Code? Open in Web Editor NEWThis project forked from marmarek/qubes-app-linux-split-gpg2
License: GNU General Public License v2.0
qubes-app-linux-split-gpg2's People
Contributors
Stargazers
Watchers
qubes-app-linux-split-gpg2's Issues
[R4.0] QUBES_GPG_DOMAIN seems to be ignored
Seems like QUBES_GPG_DOMAIN setting is being ignored on QubesOS R4.0. Each time I run gpg2 --list-secret-keys I get a Qubes dialog box asking:
Do you want to allow the following operation?
Select the target domain and confirm with OK.
Source:
Operation: qubes.Gpg2
Target:
Not a huge problem (other than that all works as expected), but kind of annoying.
My .split-gpg2-rc from the client cube:
$ cat .split-gpg2-rc
# put this file in ~user/.split-gpg2-rc and modify according your needs
#### Settings affecting the client (running gpg2) ####
export QUBES_GPG_DOMAIN=vault
...and from the server cube:
$ cat .split-gpg2-rc
# put this file in ~user/.split-gpg2-rc and modify according your needs
#### Settings affecting the client (running gpg2) ####
export QUBES_GPG_DOMAIN=vault
##### Settings affecting the server (running gpg-agent) ####
export QUBES_SPLIT_GPG2_PKSIGN_AUTOACCEPT_TIME=no
export QUBES_SPLIT_GPG2_PKDECRYPT_AUTOACCEPT_TIME=300
# to enable verbose notifications comment the folloing line out:
export QUBES_SPLIT_GPG2_VERBOSE_NOTIFICATIONS=yes
Zenity output confuses gpg
On my message, zenity displays an assertion failure error message, which somehow gets sent to GPG and interpreted as an invalid IPC command.
Document lack of security support
split-gpg2 is not security supported (yet). This should be documented.
Use a better configuration method
Right now configuration is done via sourcing shell scripts. This is rather fragile at best, and at worst can easily create misleading expectations regarding security. For instance, setting GNUPGHOME will sometimes change which keys are available via the agent, but it sometimes will not. It also prevents using socket-based qrexec for improved performance.
Key generation does not work because of pinentry problem
If I try to generate a key, I run into a problem due to pinentry: pinentry tries to access the controlling terminal, but there is no such terminal, so it fails with a confusing error.
The simplest solution is to replace the pinentry program with a trivial script that always returns OK for every command. A better solution is to always set the pinentry mode to loopback, and respond to every passphrase request with an empty response.
Command filtered: `GETINFO s2k_count`
Looks like Mailpile relies on GETINFO s2k_count; however, this is being filtered out by split-gpg2.
Is this something split-gpg2 could allow, or perhaps should Mailpile reevaluate the need for its use?
Relevant log:
2018-02-11 23:22:25.385615886: 1510: C >>> GETINFO s2k_count
2018-02-11 23:22:25.402996632: 1510: C <<< ERR 67109888 Command filtered by split-gpg2.
Strictly validate s-expressions
The s-expressions passed between from GPG to the agent are actually libgcrypt signing and decryption requests. libgcrypt documents the format of these s-expressions at https://www.gnupg.org/documentation/manuals/gcrypt/Cryptographic-Functions.html. split-gpg2 should validate these s-expressions.
Can't build Debian packages on Fedora
Building Debian packages on Fedora 25 (or a cube based on fedora-25 template) fails, since it's impossible to install a dependencies: dh-systemd and build-essential:native (no such packages available on Fedora).
Additionally, even after installing package debhelper, dpkg-buildpackage complains about it being unavailable.
Log:
$ dpkg-buildpackage -us -uc
dpkg-buildpackage: source package split-gpg2
dpkg-buildpackage: source version 0.1
dpkg-buildpackage: source distribution experimental
dpkg-buildpackage: source changed by HW42 <[email protected]>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build split-gpg2
dpkg-source: info: using options from split-gpg2/debian/source/options: --tar-ignore=.git
dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native debhelper (>= 9)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
Trying to override the dependency handling doesn't work, since debhelper plugin that would normally be provided by dh-systemd is not available:
$ dpkg-buildpackage -d -us -uc
dpkg-buildpackage: source package split-gpg2
dpkg-buildpackage: source version 0.1
dpkg-buildpackage: source distribution experimental
dpkg-buildpackage: source changed by HW42 <[email protected]>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build split-gpg2
dpkg-source: info: using options from split-gpg2/debian/source/options: --tar-ignore=.git
fakeroot debian/rules clean
dh clean --with=systemd
dh: unable to load addon systemd: Can't locate Debian/Debhelper/Sequence/systemd.pm in @INC (you may need to install the Debian::Debhelper::Sequence::systemd module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 15) line 2.
BEGIN failed--compilation aborted at (eval 15) line 2.
debian/rules:4: recipe for target 'clean' failed
make: *** [clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
Building on Debian-based distros (or cubes based on debian-9 template) works flawlessly.
Command filtered: `pinentry-mode=loopback`
Looks like Mailpile relies on pinentry-mode=loopback; however, this is being filtered out by split-gpg2. This happening regardless of whether or not any secret key is protected by a password.
Is this something split-gpg2 could allow, or perhaps should Mailpile reevaluate the need for its use?
Log:
2018-02-11 23:00:30.485636939: 1180: connected
2018-02-11 23:00:30.618741070: 1180: A >>> OK Pleased to meet you, process 1180
2018-02-11 23:00:30.619058294: 1180: C <<< OK Pleased to meet you, process 1180
2018-02-11 23:00:30.621540647: 1180: C >>> RESET
2018-02-11 23:00:30.621680104: 1180: A <<< RESET
2018-02-11 23:00:30.621822466: 1180: A >>> OK
2018-02-11 23:00:30.621886097: 1180: C <<< OK
2018-02-11 23:00:30.623717083: 1180: C >>> OPTION ttytype=xterm-256color
2018-02-11 23:00:30.623957721: 1180: C <<< OK
2018-02-11 23:00:30.625519086: 1180: C >>> OPTION display=:0
2018-02-11 23:00:30.625686597: 1180: A <<< OPTION display=:0
2018-02-11 23:00:30.626451342: 1180: A >>> OK
2018-02-11 23:00:30.626554322: 1180: C <<< OK
2018-02-11 23:00:30.627776613: 1180: C >>> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2018-02-11 23:00:30.628066076: 1180: C <<< OK
2018-02-11 23:00:30.628655543: 1180: C >>> GETINFO version
2018-02-11 23:00:30.628777449: 1180: A <<< GETINFO version
2018-02-11 23:00:30.629661940: 1180: A >>> D 2.1.18
2018-02-11 23:00:30.629775343: 1180: C <<< D 2.1.18
2018-02-11 23:00:30.629863764: 1180: A >>> OK
2018-02-11 23:00:30.629924905: 1180: C <<< OK
2018-02-11 23:00:30.630263938: 1180: C >>> OPTION allow-pinentry-notify
2018-02-11 23:00:30.630395438: 1180: A <<< OPTION allow-pinentry-notify
2018-02-11 23:00:30.630883926: 1180: A >>> OK
2018-02-11 23:00:30.630944135: 1180: C <<< OK
2018-02-11 23:00:30.631328783: 1180: C >>> OPTION agent-awareness=2.1.0
2018-02-11 23:00:30.631472520: 1180: A <<< OPTION agent-awareness=2.1.0
2018-02-11 23:00:30.632166138: 1180: A >>> OK
2018-02-11 23:00:30.632252379: 1180: C <<< OK
2018-02-11 23:00:30.632931094: 1180: C >>> OPTION pinentry-mode=loopback
2018-02-11 23:00:30.645026328: 1180: C <<< ERR 67109888 Command filtered by split-gpg2.
2018-02-11 23:00:30.645747599: 1180: disconnected
Should be a per-user systemd service
Services that should run in the context of a human user (which this does) should run under the user instance of systemd and be installed in /usr/lib/systemd/user. This also allows it to have a hard dependency on the GPG agent socket unit, which means it can avoid ever having to start the agent manually.
Being a per-user unit also allows one vault qube to expose a different set of GPG keys depending on the calling qube, by using qrexec policy to specify the user the command should run as. While this is suboptimal, there are cases where there is no good alternative ― the user may not have enough memory to run multiple vault qubes, for example.
Support filtering keys based on qrexec policy
It should eventually be possible to restrict access to keys based on qrexec policy. This also includes the actual operation to be done, such as signing vs decrypting.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.