search

keylime / meetings

Keylime meeting notes
0 stars 7 forks source link

Meeting 17/04/19 #6

Closed lukehinds closed 4 years ago

lukehinds commented 5 years ago

Project Board

https://github.com/orgs/keylime/projects/1

Attendees

Topics

Actions

Meeting notes

New Feature

Everyone likes the new feature, but we should be careful we don't break old feature.

frozencemetery commented 5 years ago

I may not make this one, but I'm sure yinz'll be fine without me :)

lukehinds commented 5 years ago

I may not make this one, but I'm sure yinz'll be fine without me :)

No worries robbie, the minutes will be dropped in here post meeting.

lukehinds commented 5 years ago

Luke Hinds @lukehinds 16:00 hi @/all agenda keylime/meetings#6 Mark Bestavros @mbestavros 16:00 Hello! Luke Hinds @lukehinds 16:01 please add comments if you want leonjia0112 @leonjia0112 16:01 Hi! Andrew Toth @atothRedHat 16:01 Hi all Luke Hinds @lukehinds 16:01 also say o/ if you're here Mark Bestavros @mbestavros 16:01 o/ leonjia0112 @leonjia0112 16:01 \o/ Luke Hinds @lukehinds 16:01 I think nabil and robbie are away so we cna start Project naming keylime/python-keylime#104 @lukehinds so my timing might not be ideal here, but better now before we get known hopefully I am not giving you all rename fatigue the proposal is to change python-keylime to keylime and possibly rust-keylime to keylime-agent and then if / when we port the verifier to rust, we can just depreciate the python code and have /keylime as the main repo (by moving all rust code into there) makes sense? I figure we could vote on this, it does not need a lot of heavy lifting to change Charlie @jetwhiz 16:05 so how would this affect packaging? would the python-based agent not be packaged, only rust? Andrew Toth @atothRedHat 16:05 what does python-keylime hold right now? Charlie @jetwhiz 16:06 python-keylime holds all of the types: verifier, tenant, tenant webapp and agent (all in python) Luke Hinds @lukehinds 16:06 @jetwhiz that's my impressopm yes *impression do you see any issue with that? Andrew Toth @atothRedHat 16:07 should those pieces be broken out into their on repos on for each component Charlie @jetwhiz 16:07 they have a ton of overlapping code, so it would be tricky Andrew Toth @atothRedHat 16:07 ports of each piece may be cleaner though Luke Hinds @lukehinds 16:07 I prefer the same repo lets cover the packaging as that is a good point. Charlie @jetwhiz 16:08 as long as we make it clear that the python-agent (in keylime) is not the one being packaged in the repos i'm just worried about confusion over two agents (and the one in the main repo not even being used/packaged) Luke Hinds @lukehinds 16:09 when we agree the rust client is stable, we should depreciate the python agent code no point maintaining both, unless you see a need to keep the python agent code active? Charlie @jetwhiz 16:10 can we just pull the rust-agent into the keylime repo in that case? Luke Hinds @lukehinds 16:10 CI testing might be challenge (thinking) I would prefer to do that when all is rust based Andrew Toth @atothRedHat 16:11 one in all or all in separate would be the 2 best options, any mix would beg for confusion, Just my 2cents Charlie @jetwhiz 16:12 yeah it feels weird having everything except the agent in one repo Luke Hinds @lukehinds 16:12 its hard to do CI then though if a rust based PR comes in, we need to use rst lint checks etc Charlie @jetwhiz 16:13 yeah that's true Andrew Toth @atothRedHat 16:13 keylime common, keylime verifier, keylime registrar, keylime agent then laguage specific dirs under each Luke Hinds @lukehinds 16:13 I don't mind having everything in the same repo as an ultimate goal. but with different langs is a challenge Andrew Toth @atothRedHat 16:14 I would say that is ok if you only intend to have 1 version of each component Luke Hinds @lukehinds 16:14 as there is only one .travis.yml per repo Andrew Toth @atothRedHat 16:15 so back to the keylime-Laguage repos Luke Hinds @lukehinds 16:15 well lets consider the rename of python-keylime, and we can still revist merging all at a later point when the synergies are there I don't think we need the python- right now. Andrew Toth @atothRedHat 16:16 Keylime should be first if nothing else Luke Hinds @lukehinds 16:16 that at least makes it easiser for those that are new to the project to understand. Charlie @jetwhiz 16:17 yeah, that seems reasonable for now Luke Hinds @lukehinds 16:17 and then when @frozencemetery is back we can chat over the rust-keylime naming along with @leonjia0112 and @mbestavros Mark Bestavros @mbestavros 16:17 :thumbsup: Andrew Toth @atothRedHat 16:18 sounds like a plan Luke Hinds @lukehinds 16:18 so it looks like if there is no one against it, I will rename python-keylime to keylime for now and handle all the readme changes , packaging efforts cool! TPM 2.0 port keylime/rust-keylime#44 @mbestavros @leonjia0112 ** keylime/rust-keylime#54 how is it going guys? leonjia0112 @leonjia0112 16:19 For renaming, I don't have much thought. TPM2.0 implementation is finished, but I ran into a problem to pass the CI. Luke Hinds @lukehinds 16:20 linky? https://travis-ci.org/keylime/rust-keylime/builds/520923619?utm_source=github_status&utm_medium=notification leonjia0112 @leonjia0112 16:21 The cargo test will do all the test in parallel, but two test cases both access the same file with will give an error occasionally. I opened an issue for that already. Luke Hinds @lukehinds 16:22 which issue is that @leonjia0112 ? leonjia0112 @leonjia0112 16:22 The CI is keep getting this error, so I am working in taking carry of this issue, but not yet finished (T.T)/ this one keylime/rust-keylime#56 Luke Hinds @lukehinds 16:23 I remember seeing this before, I thought it was rustfmt playing up leonjia0112 @leonjia0112 16:23 running cargo test locally, you won't get the error every time, but this is still an issue. Luke Hinds @lukehinds 16:25 so you plan to fix this in test tpm::tests::test_get_tpm_metadata_2? leonjia0112 @leonjia0112 16:25 porting from the current tpm1.2 functions to tpm2.0 version is done. Also added other function, which are needed in the cloud-agent. I tried, but didn't get a good solution yet. Luke Hinds @lukehinds 16:27 but it builds locally which is good, that means we can start testing it against the verifier / registrar - have you done any offline integration tests yet? i.e. use the rust agent as the main agent within the complete set of actors? leonjia0112 @leonjia0112 16:27 Actually, the server is not yet ready to handling incoming request, that should be done before we test against the verifier. Luke Hinds @lukehinds 16:28 please define "the server" is this in the agent, or the verifier / registrar? leonjia0112 @leonjia0112 16:28 the agent's http server response to the network request. Luke Hinds @lukehinds 16:29 ok, is that what you were working on @mbestavros ? Mark Bestavros @mbestavros 16:29 The POST side of it, yes Luke Hinds @lukehinds 16:29 how is that going? Mark Bestavros @mbestavros 16:30 No major roadblocks, currently working on extracting and using the U/V keys I'm not sure that work is documented in an issue, unless we consider that part of the TPM2 port Might be nice to add one Luke Hinds @lukehinds 16:31 I agree, are you ok to do that? Mark Bestavros @mbestavros 16:31 Sure, I'll add it later today Luke Hinds @lukehinds 16:31 You can then reference this issue in your commit when you make it. Mark Bestavros @mbestavros 16:31 Sounds good Luke Hinds @lukehinds 16:31 Just helps to track things, thanks man! Charlie @jetwhiz 16:32 so the existing receives from the server but can't send to it yet? Luke Hinds @lukehinds 16:32 @mbestavros best let you answer ^ Mark Bestavros @mbestavros 16:33 I'm not sure of the status of that, but I don't think we make any outgoing network requests yet Luke Hinds @lukehinds 16:34 POST would be outbound? Charlie @jetwhiz 16:34 it could be any HTTP request outbound (for the RESTful interface) some of the outbound comm code is in the verifier_common and registrar_client files, I think leonjia0112 @leonjia0112 16:36 Now server only take care of quote request Mark Bestavros @mbestavros 16:36 Pretty sure we haven't touched that yet Yeah leonjia0112 @leonjia0112 16:36 will get back to it once I am done with tpm Luke Hinds @lukehinds 16:37 if you can guys, try to get an issue logged for each work peice if you can, or have use some markdown checkboxes [ ] in the main TPM issue. Charlie @jetwhiz 16:37 ok, gotcha. so registration and verifier comms are still todo, but much of the tpm2.py code was ported over to rust? Luke Hinds @lukehinds 16:37 TPM2 port issue that is leonjia0112 @leonjia0112 16:37 gotcha Luke Hinds @lukehinds 16:38 ok, lets move on. vTPM no progress just yet, nabil is away and I have been on other items Backport 3.x TPM2-Tools keylime/python-keylime#92 @jetwhiz ok, if nothing new @jetwhiz just to keep abreast of things. Charlie @jetwhiz 16:39 still need to make the keylime changes to hook the new 3.X tools in Luke Hinds @lukehinds 16:39 ack Python 3 support keylime/python-keylime#32 I have done quite a bit on this, but stuck on JSON serialization Charlie @jetwhiz 16:41 do you want to chat more about that @lukehinds ? i think you had some Qs about JSON Luke Hinds @lukehinds 16:41 since Python 3 , 'bytes' are not JSON serializable and we load the key into private.json in base64 did you come accross that in your previous port attempt charlie. I had a try and chaning into utf-8 on the fly, but started to dig myself into a hole. I think it needs a rethink of how we approach the action of storing into the json file Charlie @jetwhiz 16:43 i'm not seeing any JSON changes in mine Luke Hinds @lukehinds 16:43 https://github.com/keylime/python-keylime/blob/master/keylime/ca_util.py#L448 its json.loads that complains Charlie @jetwhiz 16:45 they aren't strings? or did you convert them to bytes for the crypto libs? Luke Hinds @lukehinds 16:46 the private key is presented to json_load as base64 , so it has a b\ I tell you what, shall I email you with the stack trace..I don't have it to hand right now, I need to bring up a VM with the python3 env set up and the py3 deps in place? Charlie @jetwhiz 16:49 i'll have to take a look, but the base64 output should be strings (we send them over HTTP GET requests) Luke Hinds @lukehinds 16:50 here we go, lets see how well this is handled by gitter Charlie @jetwhiz 16:50 (we use base64 to convert from binary blobs into strings that can be transmitted) Luke Hinds @lukehinds 16:50

Traceback (most recent call last): File "/usr/local/bin/keylime_verifier", line 11, in <module> load_entry_point('keylime==1.2', 'console_scripts', 'keylime_verifier')() File "/usr/local/lib/python3.6/site-packages/keylime-1.2-py3.6.egg/keylime/cloud_verifier_tornado.py", line 495, in main context = cloud_verifier_common.init_mtls() File "/usr/local/lib/python3.6/site-packages/keylime-1.2-py3.6.egg/keylime/cloud_verifier_common.py", line 122, in init_mtls ca_util.cmd_init(tls_dir) File "/usr/local/lib/python3.6/site-packages/keylime-1.2-py3.6.egg/keylime/ca_util.py", line 153, in cmd_init write_private(priv) File "/usr/local/lib/python3.6/site-packages/keylime-1.2-py3.6.egg/keylime/ca_util.py", line 423, in write_private priv_encoded = json.dumps(priv) File "/usr/lib64/python3.6/json/__init__.py", line 231, in dumps return _default_encoder.encode(obj) File "/usr/lib64/python3.6/json/encoder.py", line 199, in encode chunks = self.iterencode(o, _one_shot=True) File "/usr/lib64/python3.6/json/encoder.py", line 257, in iterencode return _iterencode(o, 0) File "/usr/lib64/python3.6/json/encoder.py", line 180, in default o.__class__.__name__) TypeError: Object of type 'bytes' is not JSON serializable
something else I noted:
>>> from Cryptodome.Random import get_random_bytes

import base64
bytes = get_random_bytes(32)
out = base64.b64encode(bytes)
print (out)
b'MslZFSwMbfAUWuGBVc5VHejHTqUH66C2iQBPd9pbClg='
out = base64.b64encode(bytes).decode('utf-8')
print (out)
MslZFSwMbfAUWuGBVc5VHejHTqUH66C2iQBPd9pbClg=
type(out)
<class 'str'>
we load into the json array as base64
return {'revoked_keys':[]},base64.b64encode(crypto.generate_random_key())
TypeError: Object of type 'bytes' is not JSON serializable

I tell what, I will get a git issue underway, and we can tag it with question :) Charlie @jetwhiz 16:53 yeah that sounds good, i don't see any changes in my old py3 branch related to that (mine were being treated as strings) Luke Hinds @lukehinds 16:53 oh hold on, a colleague got back to me it might be a python version dep https://bugs.python.org/issue10976 python 3.6 Charlie @jetwhiz 16:54 yeah that looks promising, what are you running? Luke Hinds @lukehinds 16:54 I will take a look yep, let me check it over at least we can then do a version check if 3.6 is kaput so looking at the rest of this list, we can finish up. fedora packaging is contingent upon py3 port being complete and its looking like I might have that resolved now any other import biz folks you want to raise? Charlie @jetwhiz 16:56 nothing else here are we still targeting October as the deadline, or sooner for packaging, etc.? Luke Hinds @lukehinds 16:57 much sooner I hope..I want it in review by the end of this month. we have missed 30, but 31 it has to be in there. and a copr repo for earlier releases Charlie @jetwhiz 16:58 yeah we definitely want to hit F31 Luke Hinds @lukehinds 16:59 yep, I have that marked as a #1 priority for me. ok, great - thanks all!