Skip to content

Meeting notes

Jump to bottom
Philipp Kern edited this page Oct 11, 2024 · 27 revisions

Meeting notes

2024-10-11

  • @burgerdev to close PR #57.
  • @burgerdev still wants to write a CLI in Rust, using clap. Discussion of Rust's properties ensued.

2024-06-20

  • PR #176: @burgerdev to review once more after the meeting.
  • Man pages: pandoc and using Markdown
  • GLOME server in Go PR from 4 years ago: should probably be closed
  • CLI can already generate tags on the command line. @vvidic wrote a test for Debian with expect that uses it.

2024-03-21

  • Rollouts of new versions are in progress, which means less reliance on /v1/ support in login eventually. (We can already assume that clients can all use the /v2/ protocol.)
  • Valentin uploaded GLOME to Debian. 🥳
  • Rust PR #175:
    • We are in agreement that we should abstract away from a) low-level u8 arrays and b) dependent crates like Dalek, and implement our own trait for the functionality we rely on.
    • Markus will take another look at the code.

2024-01-11

  • Philipp is probably going to approve #172 (dependabot) soon.
  • After the release is before the release:
    • Leftover code from the old login protocol (e.g. Go cleanups)
    • Philipp to talk to Luke about one straggler platform inside Google
  • Should there be OpenSSL-style encrypted private keys for the CLI?
    • Sounds like a good idea for additional security, especially if we were to use OpenSSL and could use other credential storage options
    • Maybe another opportunity for Rust; Markus' branch had an example of a CLI as well already
    • Discussion about FIPS compliance
    • Tink actually does have a Rust port: https://github.com/project-oak/tink-rust/
    • Let's try Rust and Markus will try to work on it

2023-10-05

  • Markus has landed the C PR.
    • The in-tree Go server implementation only supports /v1/ - despite the login implementation already existing for /v1/.
  • The Go server has some assumptions around authorization that are not portable.
    • No additional context.
    • Maybe there should be an OPA implementation to actually reason properly about authorization contexts.
  • For C we are there.
  • Should we just tag a v0.1?
    • Markdown stuff - glome-login protocol description is /v1/ right now
    • There should at least be some disclaimer at the top if it's out of date and we want to tag it
    • Markus will finish the doc rewrite and then Markus will do the honors
  • https://github.com/google/glome/pull/169 status: Only a description change left, @pkern to ping the author again.

2023-09-12

  • Open PRs:
    • Luke's INI parser for Go GLOME login (needed internally)
      • Piotr asks if it's valid TOML. It probably... isn't. Because strings are quoted.
      • We could use a subset?
      • We should at least document why we didn't use another parser for this and rolled out own.
  • Code on the C implementation of the protocol is definitely lost.
    • Markus will write up a first PR by end of this week, i.e. by 2023-09-15.

2023-07-06

  • Trying to recover state after a long time of no meetings.
  • #100 (closed PR) had some checkboxes, which should have been in an issue.
    • RFD001 still needs to be folded into the protocol docs.
    • Support for Go is there. Login is not implemented in Python. (Only on delroth's GitHub.)
    • C is hard. Probably not getting to this before August. Markus had some draft code and Valentin could take a look at it. We don't need to preserve backwards compatibility there.
  • #126 (README) is done.

2023-05-11

2023-04-06

  • Followup on AIs:
    • /v2/ proposal has been reviewed, Markus is still unhappy with the overall conclusion
      • Encoded tagging is mildly inconvenient, but you need some encoding to put it into the hashing function; basically tag the suffix of the URI
      • PR is fine as-is, we are tagging the encoded version of the hostid/hostid-type/action triplet
      • Still needs to be implemented
    • README is still open.
    • Super-linter:
      • Linters should always have formatters.
      • We'd need to reformat the Markdown.
      • Some GitHub linters have a suggestion mode.
  • We should be able to tag the release once Markus' PR is in.

2023-03-08

  • Meeting time conversation:
    • First Thursday of the month, 11 am Berlin time
    • Next time will be Easter Thursday though, so this might still get moved around
  • l9i@'s AIs:
    • Reviewing Markus' proposal for /v2/
      • There is still a pending local cosmetic change not pushed yet
      • What would be the meaning of prefix7? Only an index.
      • Is the first bit still meaningful? Yes. But maybe we should drop prefix1 and move to a prefix8. 127 indices should be fine, even Google can count.
      • There is still the nice property that you can get prefixes from just a key without versioning.
      • We should mostly distinguish between first byte is an index or prefix of a public key.
      • Fun fact: The highest bit of the last byte of a public key does not matter.
    • README to review.
    • Java deletion PR for grabs.

2023-02-08

  • Discussion of l9i@'s PRs:
    • Most important part was to reintroduce the /v1/ prefix, which has now been done (i.e. reverted)
    • Who is going to fix the Java/Go/Python libraries?
      • l9i@ is in favor of nuking Java.
      • Maybe Java doesn't even need an update. But we might want it in the future for an Android app.
      • There was an API misuse issue with X25519. But we might be using Tink now. But then Tink seems to have no plans to support X25519.
    • Yet another PR waiting for l9i@ to review protocol changes: PR #102.
      • We can make it a v1 change, but there is a breaking change in the message action: Slashes will need to be encoded.
      • We are still using the 7bit prefix, but just for key IDs - not for public key prefixes.
  • There is a release milestone that has issues assigned to it.
  • AI(pkern): Reply to #60.
  • AI(markusrudy & pkern): Review l9i@'s two PRs.
  • AI(l9i): Review PR #102.
  • Once those AIs are done, we tag the release.
  • l9i@ still wants to address URL -> challenge in Go. We should have the same test vectors in Go as well as C.
    • It cannot be done mechanical because sometimes "url" actually make sense.
  • We still reserve ourselves the right to break the API with the 0.x release.
  • AI(l9i): Drop Java for now (it will live on in the git history) and fix Go.
  • It's not worth rewriting the CLI right now.

2022-12-06

  • There are some concerns about dropping the version prefix on PR #131. We are going back in time on that PR.
    • There are concerns around how to handle the next version of the protocol when we remove /v1/ from the challenge.
    • We are also making url-prefix an alias to prompt and make url-prefix a hidden, undocumented feature.
  • pkern@ reviewed vvidic@'s Debian packaging and sent a patch with some suggestions.
    • We will need manpages for Debian.
    • It might be useful to generate them from Markdown.
    • We might also want a glome-protocol(7) linking to glome(1) and others.
  • Discussion about semver and soversions. semver allows breaking changes within 0.*.
    • semver would mandate 0.1.0 as the first version.
  • Can we drop Java support?
    • Send a PR and we discuss it there.

2022-11-10

  • Discussion of open Pull Requests
    • PR #131: Rename url-prefix to prompt
      • Dropping the entire parsing vs. that being a bigger change: The PR was about changing the name and there should be a separate PR for dropping the parsing.
      • Do we want people to paste in arbitrary strings that just happen to end in a GLOME challenge or should we accept just the GLOME part in the first place?
      • Take whatever you got as the login string.
    • PR #109: Public key format at rest
      • No time to work on this.
  • Discussion of a new language for the CLI
    • We don't have embedded dependency constraints for the CLI vs the login binary/PAM
    • Consensus that Go would be an acceptable choice
    • How much ongoing development do we expect in the CLI?
    • Public key at rest, e.g. PEM-encoded private keys would need to go into the CLI
    • vvidic is happy to work on C code and OpenSSL dependency can provide PEM
  • Debian release cycle
    • We should probably upload something now.
  • Blockers for the release
    • Documentation
      • Piotr has some dusty changes on his laptop for the documentation
    • Config changes should land first
    • Release a 0.9
      • PAM module
      • CLI
      • login binary
    • For Debian three different binary packages, maybe without automatic addition to the PAM stack - vvidic to do the first stab

2022-07-05

  • README.md rewrite is getting there.
  • Users can see different prompts depending on which implementation they use:
    • glome-login uses Obtain the one-time authorization code from:\n%s%s
    • pam_glome uses GLOME link: %s%s
    • Piotr's suggestion is to unify that and make it configurable. That could replace the url-prefix option.
  • Once these two changes are in, we should finally tag the current release.
  • Short discussion about introducing a KDF. We agreed that it is not necessary.
  • PR review

2022-03-15

  • Documentation is still pending.
  • Piotr wrote a short spec for multi-party support.
    • Backwards compatibility: n=1 is a special case of multi-party.
    • Keys would have weights. With no annotation the weight is 1. Default threshold is 1.
    • Client would prompt for authcode until the threshold is met.
    • Authcode, optionally with a space and a comma list of keyids.
    • We could try all keys, implications for brute-force attacks but this should be fine with a small number of keys.
    • Authcodes can be XORed together. If an authcode matches, it subtracts the weight of the key.
    • Unknown keys cannot be part of an XORed code.
    • The compact version is mostly useful if you cannot copy'n'paste.
    • We can do the MPA without the XORed authcode first.
    • Keyset ID in the challenge request? Require the key ID in the authcode? That would allow us to distinguish invalid authcode from unknown key.
    • For the KVM case it makes sense to have only a single challenge URL with a QR code.
    • We might want to indicate the keyset by commit/CL number.
    • Print multiple URLs when the URL field is set on the key.
  • glome-js would be a good idea.

2022-02-04

  • Valentin contributed Docker code and documentation. \o/
  • Piotr will now write missing documentation.
    • Getting started guide with just the CLI
  • Fixing Matrix room permissions.
  • Once we have the getting started guide we can tag the release?
    • Wait for Valentin's refactoring to land (which is close now)
    • Markus to work on the public key format PR again - RfD 002
      • Let's not have 32 raw bytes for the public key
      • PKCS#8 for the private key to password protect it? Could be done later
      • With the INI format we can now have sections and could represent multiple parties. That wasn't possible with the original proposal.
      • Section name: party name as the section name?
      • Public key as an attribute, weight, prefix/URL/URI (manual-approval://username/v1/...?) - but nothing really cares about it except for escaping
      • We are assuming that it's a URI in some legacy tools
      • PR #111 will allow an empty string (the "delroth" case)
  • Do we have any opinion on the server example PR?   - Definitely not ready for merging. Markus gave up on it after spending some more time on it.
    • Markus is not a believer in turnkey solutions.
    • Previous state had an authorizer that could be written in Lua.
    • The current state shells out to an authorizer that's a configurable binary.
    • Expect an authentication in front.
    • Authenticated principal and whatever is in the action.
    • Enterprise deployments will fork anyway.
  • Markus is torn on example code in the main repository.
    • We should make it clear what's intended for production use and what's an example.
    • An examples directory would be obvious enough.
    • Eventually we should talk about why more Rust-y/functional approaches are not supported but Python and Java are.

2022-01-11

  • Valentin's two PRs:
    • Current approach: Passing around function pointers, alternatively we could do a simple fake PAM header
  • Complexity of a new configuration format was sort of rejected internally to unblock the migration
  • Interest in breakglass/MPA?
    • Maybe long-term
    • Piotr is still working on a proposal, wants to finish that over the weekend (including the XOR compression of the authcode)
  • Releases: can we make one?
    • Piotr volunteers to write a user guide when we have one
    • v0.1: minimal set of steps to make this work
      • Set up glome-login and generating authcodes on the command-line
      • CLI supports login thanks to Valentin!
      • Docs within the release?
      • What binaries would we need? Piotr wants an easy experimentation environment. This might or might not be Docker-based.
      • Build vs. experimental setup docs
      • Maybe run a telnet service in the Docker container
    • Valentin's plan for this year: unify the flag handling and introduce long flags

2021-11-03

  • General disappointment about the CLI/library being written in C because of dynamic memory allocation
  • Key configuration format
    • Urgently: Settle on a stable config file format.
    • Command-line likely needs to accept the same kind of format.
    • A single public key is also a valid config file, which is neat.
    • Proposal (#109) specifies options as key/value pairs. SSH has comma-separated options. Current proposal has optional space separated key/value pairs and then key type and key. Top-level (newline) vs. within line (space) vs. options (comma)? Should we follow SSH's lead here? But SSH also supports spaces in options and uses quoting.
    • How about we ban ' and " so that we are backwards-compatible?
    • Reading the room: Let's go with commas.
    • foo <key type> <base64>[<comment>]
    • Do we ever want to store anything else than keys? Yes, we need options on keys. Currently we do not have any global configuration, everything is per key.
    • Maybe we could use the flagfile approach where flags are loaded from a file first and then flags from the command-line? Wouldn't that be underspecified for key options as well?

2021-10-19

  • Copybara:
    • No update. Pointing back to the meeting notes of the last meeting.
  • glib dependency:
    • We are trying to get rid of it.
  • Key format proposal:
    • Should this look like SSH authorized keys?
  • Multi-party approval proposal:
    • Piotr has a draft proposal.
    • How do I figure out as the prod-oncaller if the key is supported or not? Without additional context, you can't.
    • Explicit mode can provide explicit feedback.
  • User guide:
    • Automated releases: How about we do binary releases on GitHub?
    • Crazy idea: Have a server implementation in Javascript that's self-contained and can be run in the browser.
    • Downstream NixOS/Debian
    • Actually telling them how to use it

2021-10-05

  • How would MPA work?
    • Right now we expect a single service key. For MPA we would require multiple keys.
    • The easy way: Prefix the tag. The messy way: Try all the keys. You can be explicit about which keys have been accepted and which haven't for debugging
    • The slightly more sophisticated way: Assign some weights to the keys. People keys would have smaller weights for n out of m, service key would have unilateral trust.
    • The hard part: If your N is sufficiently high you need to type multiple keys. You could XOR all of them. But then you have no debugging.
    • The challenge can be shared with whomever and is not dependent on the service's public key.
    • Tricky: Currently we encode which key we expect. Make a leap of faith. Version the keyset? It's mostly about debugging, you could just ignore the key indicator.
    • PAM can have arbitrary number of prompts, so can provide feedback of what is accepted or not.
  • Future of glome-login: Make we could statically link the PAM module into a small wrapper that provides glome-login without actually relying on a PAM stack.
  • GitHub Source of Truth: We are going to try again. Maybe we should update README internally (or externally?) about how to make contributions.
  • Topic to discuss next time:
    • Java and Python: Tests were broken in Python, that was the only reason that was touched.
    • User guide and binary releases
    • Adding GLOME to Debian/nixos

2021-07-27

  • How to do meeting notes?: We're using the GitHub wiki. But it turns out that these pages do not make it into the main git repository. This is in contrast to GitHub Pages, which use a branch in the main repository.
  • How to do design docs?: Let's use a docs/ subdirectory with a Pull Request.
  • l9i has ideas about a new version of the URL. We need some kind of checksumming of the message, also to sanity-check the encoding of the message. We have prefixN in the protocol. l9i has a XOR-based proposal based on a hash of the message to XOR into the public key. We could also use HMAC with the public key as the key part.
  • markusrudy would like to see an init/update/finialize API for glome.c.
Clone this wiki locally