-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
No GnuPG. Just Python.
The private key material is decrypted. It is up to the library creating the keys to parse the bytes streams and retrieve the MPIs (along with the key type). See section 5.5 of RFC4880 (https://tools.ietf.org/html/rfc4880#section-5.5)
No GnuPG. Just Python.
The private key material is decrypted. It is up to the library creating the keys to parse the bytes streams and retrieve the MPIs (along with the key type). See section 5.5 of RFC4880 (https://tools.ietf.org/html/rfc4880#section-5.5)
|
||
pip3.6 uninstall -y lega | ||
pip3.6 install pika==0.11.0 fusepy | ||
pip3.6 install git+https://github.com/NBISweden/LocalEGA.git@feature/pgp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe the feature/pgp
branch should not be hardcoded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. But it must be right now in the PR, and then another PR will follow when that PR is merged into dev.
@@ -53,6 +53,7 @@ bootcmd: | |||
runcmd: | |||
- mkfs -t btrfs -f /dev/vdb | |||
- pip3.6 uninstall -y lega | |||
- pip3.6 install pika==0.11.0 psycopg2==2.7.3.2 | |||
- pip3.6 install git+https://github.com/NBISweden/LocalEGA.git@feature/inbox-fuse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a branch feature/inbox-fuse
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was :p .... and that should be updated. Good catch!
- pip3.6 install git+https://github.com/NBISweden/LocalEGA.git@feature/inbox-fuse | ||
- systemctl start ega-socket-forwarder.service ega-socket-forwarder.socket | ||
- systemctl enable ega-socket-forwarder.service ega-socket-forwarder.socket | ||
- pip3.6 install pika==0.11.0 pycryptodomex==3.4.7 psycopg2==2.7.3.2 cryptography==2.1.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
psycopg2==2.7.4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job, but I have to mention that we should probably try to avoid such a huge PR's: it's really hard to review everything at once.
.travis.yml
Outdated
@@ -7,10 +9,12 @@ before_install: | |||
# https://elk-docker.readthedocs.io/#es-not-starting-max-map-count | |||
# mostly used by ELK stack; Solving issue #252 | |||
# - sudo sysctl -w vm.max_map_count=262144 | |||
- pip3.6 install pgpy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need Python on the "host" machine? Is it for replacing PGP keys generation in bootstrapping from GPG to Python implementation? Do we really need this replacement? I feel like it's redundant because GPG is pre-installed on Ubuntu and we don't need to install anything else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No we don't, but here is the issue we fixed with it.
I explain.
We can use GnuPG to generate a key (as we used to do) and export the public key. However, to export the secret key, we need to be at the prompt to type the passphrase. So, that doesn't work for us (and tell me how we could make it work if you know), so we generate the public/private keys in another way (using the PGPy python module).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Isn't that what we need for this to work: https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it was exactly what we used to generate the key.
That generates a keyring, and you can export the public from it.
However, to export the secrete key, the passphrase is needed (and prompted).
chmod 744 ${PRIVATE}/${INSTANCE}/gpg/public.key | ||
rm -f ${PRIVATE}/${INSTANCE}/gen_key | ||
${GPG_CONF} --kill gpg-agent | ||
# Python 3.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same concern as above: I'm not sure if we need to replace PGP implementation on the host machine for bootstrapping.
FROM centos:7.4.1708 | ||
LABEL maintainer "Frédéric Haziza, NBIS" | ||
FROM python:3.6-alpine3.4 | ||
LABEL maintainer "NBIS SysDevs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been waiting for this to happen for so many months :) Finally, the maintainer label is expanded to more than one person :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's hard to have good comments on the code since there's so much bitwhacking and such.
This looks to me like a more or less one to one implementation of the pgp protocol. It would be nice with a highlevel overview on how the pgp decryption thing works. Explain what a packet is for example. And have some idea about the flow through the different pieces of the code. I usually don't ask for documentation but I think it would be nice with more documentation on all of the packet classes.
lega/openpgp/utils.py
Outdated
return data | ||
|
||
|
||
# See 3.7.1.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.7.1.3 what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RFC 4880
That's the one describing the OpenPGP standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so the comment can be
# See 3.7.1.3 of RFC 4880
lega/openpgp/__main__.py
Outdated
LOG.debug("###### Decrypting session key") | ||
# Note: decrypt_session_key does not know yet the key ID. | ||
# It will parse the packet and then contact the keyserver | ||
# to retrieve the private_key material |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got confused by this comment. I would like something on the lines of:
Note: decrypt_session_key does not know yet the key ID.
It will parse the packet and then use the provided function,
fetch_private_key, to retrieve the private_key material```
lega/openpgp/iobuf.py
Outdated
import io | ||
|
||
class IOBuf(object): | ||
""" Some description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
lega/openpgp/packet.py
Outdated
|
||
PACKET_TYPES = {} # Will be updated below | ||
|
||
def parse_one(data): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parse_next_packet(data)
?
lega/openpgp/packet.py
Outdated
|
||
filename_length = read_1(self.data) | ||
if filename_length == 0: | ||
# then sensitive file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, it should have been on line 523
lega/openpgp/utils.py
Outdated
return f'OpenPGP Error: {self.msg}' | ||
|
||
|
||
def read_1(data, buf=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think read_X
function s should be more generic read_bytes(num, data, buf=None)
and also the get_intX
should be byte2int(b, width)
(width is not technically needed unless you want to assert). This is unless there is a big performance hit by doing it this way. If there's a performance hit I think longer names would be better read_1_byte
and so forth.
I think all of these functions should be called read_1_byte
, read_2_bytes
and so forth. To make it easeier to read. And get_int2
should perhaps be called byte2int(b, width)
and then just have it dynamiclly do the right convert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That comment was confusing, you can ignore the last paragraph.
That does not solve the problem on Travis
They are uploaded to docker.io already and we don't build the images.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I bless this worthy for merge
We totally remove the dependency towards GnuPG (2.1) (even in the bootstrap step)
There is no need to use the gpg-agent, the socket forwarder/proxy and patch the GnuPG binary to locate the agent socket in a non-temporary location on disk. Updated RPMs are not necessary anymore.
We created a python script that follows RFC4880 for decryption. The script does not load the whole file to decrypt in memory, but it streams it. This allows us to handle huge files.
The code uses generators: A simple way to instantiate a function and run it step-by-step. This is how the script "produces" decrypted data as it goes.
The keyserver was also updated and answers request over HTTPS. This resolves issue #259.
The ReST endpoints are easy to adjust (if necessary) and described in the extracted documentation.
Finally, for the docker deployment, we removed many images. We keep only one base image (an upgraded centos-base including python) and the inbox image. The Terraform deployment is also updated accordingly.
Run the following asciinema demo to see it in action.