Don't overuse the keyring #8687

hroncok · 2020-08-03T10:12:07Z

See the individual commits and their messages.

hroncok · 2020-08-05T16:41:40Z

OK, I've verified this works as expected via https://gist.github.com/encukou/7d227abb62b50af5ed3539dfb725331d (thanks @encukou).

I have a video record of the behavior I can share with the reviewer if needed.

pradyunsg

LGTM, based on a desk-review and reading lots of related code in requests/keyring/pip.

The automated test seems "close enough" to me and I'm happy to trust @hroncok that this works based on their manual tests. :)

pradyunsg · 2020-08-07T09:18:32Z

I'm wondering if we should slot this into 20.2.2 -- any thoughts from others on this front? It's technically not a bugfix for something added in 20.2, but it's a substantial enough improvement that we should release this ASAP IMO.

uranusjr · 2020-08-07T09:33:57Z

I agree, it’s better to get this out sooner than later.

chrahunt · 2020-08-07T13:05:08Z

src/pip/_internal/network/auth.py

        # Prompt the user for a new username and password
-        username, password, save = self._prompt_for_password(parsed.netloc)
+        save = False
+        if not username or not password:


Will this have an impact on people that have stored API keys in keyring, or have only provided a username or password in response to a prompt? Not sure how prevalent that is but it can appear as only one of these being set.

For context on single-part login credentials, see #6796.

In other words, this should probably be: if not username only, right?

So I took a closer look. Previously we did:

Check up to 4 places (including keyring) for credentials based on the request URL (_get_new_credentials)

Make request

Get 401 and unconditionally prompt user for credentials with the response URL (handle_401)

Make followup request (handle_401)

Get 401 and warn user (warn_on_401)

Now we do:

Check up to 3 places (not keyring) for credentials based on the request URL (_get_new_credentials)

Make request

Get 401 and check up to 4 places for credentials (including keyring) based on the response URL (handle_401)

If that doesn't return something reasonable, then prompt the user

Make followup request (handle_401)

Get 401 and warn user (warn_on_401)

I think there's a few things to note with the changes we're making here:

The response URL may be different from the request URL in case of redirects, so the second time getting the credentials may behave differently

In the case where the response URL and request URL are the same, it may just try the same credentials again incorrectly

The response URL shouldn't contain credentials, so we don't have to worry about retrying with the same embedded credentials

It seems pretty complicated and to make headway we'd probably want to refactor some of this class so it doesn't get worse. Maybe we can avoid that and just disable keyring for pypi URLs? Especially if this is a change people want to get in soon.

From the last three points:

I think this is the correct behaviour. Handling redirects feels like goodness (e.g. I can bit.ly an index URL), and if a redirect turns out to be malicious, we don't want to pass along legitimate credentials to a different site

Unavoidable, probably? But we're in a failure case by then anyway, so an extra request is not the end of the world.

Correct, though if _get_new_credentials can map it back to a user-specified index url that has embedded credentials, those will be used

It is complicated, but I think this all lines up.

For the single-part credential issue, we probably want if not username and not password: - assuming that if we got a partial credential that we should still try it. _get_new_credentials has the logic for trying to turn a partial credential into a full one.

src/pip/_internal/network/auth.py

chrahunt · 2020-08-07T13:10:53Z

src/pip/_internal/network/auth.py

@@ -110,7 +112,7 @@ def _get_index_url(self, url):
        return None

    def _get_new_credentials(self, original_url, allow_netrc=True,
-                             allow_keyring=True):
+                             allow_keyring=False):


Have we looked at the impact this might have on keyring providers and associated package index assumptions? From #8103 it seems like Azure DevOps gives us a redirect, not a 401, when authentication is needed, and so may depend on our eager usage of artifacts-keyring. Not that it should necessarily block us, but this may not be a low impact change.

Honestly, I have no idea. My drive is to fix this for users who use the default pypi.org index. While I've tried to make it work for the others as well, I don't have access to such setups.

Great point. Can we just disable the initial keyring support for pypi-related URLs? We keep them here. I think that would narrow the scope of this enough that we can defer investigating my previous concern.

FWIW, Azure DevOps should return 401 now, but it's filtered on user agents to make sure that people who get given the URL land on a useful page. So you can see it through an actual pip install, but likely not if you curl directly.

pradyunsg · 2020-08-10T15:03:53Z

@chrahunt @hroncok Are there more changes necessary here on this PR right now? If yes, does anyone have a rough estimate about when they might be addressed?

This is the only outstanding PR in the milestone right now. If this is gonna take more than a couple of days or so, I'd like to cut 20.2.2 release without this.

hroncok · 2020-08-10T15:36:05Z

I won't be bale to work in all the stuff that @chrahunt talked about any time soon.

@chrahunt Can we get the first commit in for now?

pradyunsg · 2020-08-10T15:42:17Z

I don't speak for Chris, but I'd certainly be OK with that. :)

pfmoore · 2020-08-10T17:01:05Z

My only concern is that @chrahunt seems to be suggesting that we might break people using this for Azure DevOps. I don't have any particular opinion on the correct thing to do here, but if that is a risk (and not just my misunderstanding) do we have a plan for the possibility that we release 20.2.2 with this in, and immediately get cries from Azure users that we need a 20.2.3 to fix their issue?

(I'm fine if that plan is "tell them they'll have to pin to 20.2.1 or wait for 20.3", I just think we should know up front what we expect to say).

pradyunsg · 2020-08-10T19:19:19Z

I'll mostly cut this tomorrow/day-after (~12/36 hours?) and I'll be around for at least 5 hours after that. If stuff goes down, I'll be able to cut a 20.2.3 that just reverts the offending commit.

That's assuming I get a response from Chris here that he thinks adding both commits would be better than just one. If not, I think it'd be OK to force-push on this branch (I'm assuming Miro hasn't checked off the relevant box) and merge just the first commit.

hroncok · 2020-08-10T19:24:58Z

See #8744 for just the first commit.

chrahunt · 2020-08-10T23:45:10Z

Are there more changes necessary here on this PR right now?

I'd be mostly OK with this PR if we just scoped it to PyPI URLs. If we go that route we may want to confirm that there are no plans to offer private repos on PyPI anytime soon.

I won't be bale to work in all the stuff that @chrahunt talked about any time soon.

Sorry if I worded it poorly. In my mind I think all my concerns would be addressed if we just set allow_keyring to False on the first request for PyPI URLs. If we don't want to do that then it gets more complicated, as described in #8687 (comment).

@chrahunt Can we get the first commit in for now?

I'm totally on board for that, I gave my 👍 on #8744.

My only concern is that @chrahunt seems to be suggesting that we might break people using this for Azure DevOps.

Yes, I think that's a risk, based on what we've seen in a few recent issues. I have some instructions here and can test shortly.

chrahunt · 2020-08-11T00:10:12Z

I was able to successfully install an artifact using this branch and the instructions from #8103 (comment).

output

$ ./env/bin/python -m pip install -vvv --extra-index-url=https://pkgs.dev.azure.com/chrahunt/example3/_packaging/exampl
e3-feed/pypi/simple/ example3
Using pip 20.3.dev0 from /tmp/user/1000/tmp.AfSvFq6j8i/env/lib/python3.8/site-packages/pip (python 3.8)
Non-user install because user site-packages disabled
Created temporary directory: /tmp/user/1000/pip-ephem-wheel-cache-dlpuqld8
Created temporary directory: /tmp/user/1000/pip-req-tracker-gvbk9pnb
Initialized build tracking at /tmp/user/1000/pip-req-tracker-gvbk9pnb
Created build tracker: /tmp/user/1000/pip-req-tracker-gvbk9pnb
Entered build tracker: /tmp/user/1000/pip-req-tracker-gvbk9pnb
Created temporary directory: /tmp/user/1000/pip-install-ys6ad2ys
Looking in indexes: https://pypi.org/simple, https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/
2 location(s) to search for versions of example3:
* https://pypi.org/simple/example3/
* https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/
Fetching project page and analyzing links: https://pypi.org/simple/example3/
Getting page https://pypi.org/simple/example3/
Found index url https://pypi.org/simple
Looking up "https://pypi.org/simple/example3/" in the cache
Request header has "max_age" as 0, cache bypassed
Starting new HTTPS connection (1): pypi.org:443
https://pypi.org:443 "GET /simple/example3/ HTTP/1.1" 404 13
Status code 404 not in (200, 203, 300, 301)
Could not fetch URL https://pypi.org/simple/example3/: 404 Client Error: Not Found for url: https://pypi.org/simple/example3/ - skipping
Fetching project page and analyzing links: https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/
Getting page https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/
Found index url https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/
Looking up "https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/" in the cache
Request header has "max_age" as 0, cache bypassed
Starting new HTTPS connection (1): pkgs.dev.azure.com:443
https://pkgs.dev.azure.com:443 "GET /chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/ HTTP/1.1" 401 307
Found index url https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/
Getting credentials from keyring for https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/
Starting new HTTPS connection (1): pkgs.dev.azure.com:443
https://pkgs.dev.azure.com:443 "GET /chrahunt/example3/_packaging/example3-feed/pypi/simple/ HTTP/1.1" 401 307
Starting new HTTPS connection (1): pkgs.dev.azure.com:443
https://pkgs.dev.azure.com:443 "GET /chrahunt/example3/_packaging/example3-feed/pypi/simple/ HTTP/1.1" 404 46
Found credentials in keyring for pkgs.dev.azure.com
Status code 401 not in (200, 203, 300, 301)
Looking up "https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/" in the cache
Request header has "max_age" as 0, cache bypassed
https://pkgs.dev.azure.com:443 "GET /chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/ HTTP/1.1" 200 None
Updating cache with response from "https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/"
Caching b/c of expires header
  Found link https://pkgs.dev.azure.com/chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl#sha256=ff49370bdba639695bf4d3e96b80b6b0e8a3c65011c1cef658a3885c7d913c58 (from https://pkgs.dev.azure.com/chrahunt/example3/_packaging/example3-feed/pypi/simple/example3/), version: 0.1.0
Given no hashes to check 1 links for project 'example3': discarding no candidates
Using version 0.1.0 (newest of versions: 0.1.0)
Collecting example3
  Created temporary directory: /tmp/user/1000/pip-unpack-4rb_2u_z
  Looking up "https://pkgs.dev.azure.com/chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl" in the cache
  No cache entry available
  https://pkgs.dev.azure.com:443 "GET /chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl HTTP/1.1" 303 0
  Status code 303 not in (200, 203, 300, 301)
  Looking up "https://ajhvsblobprodcus363.blob.core.windows.net/b-0b71cd34f9c34172994c8b112c0efbc5/DBCE858FD979095ABFDDD6486916184A6D96809832BC940EDF646466AA55BB4D00.blob?sv=2019-02-02&sr=b&si=1&sig=CLumZkVQO3JWN3JIWgGeIvjOzsJ7dGughsR4UJwXkRA%3D&spr=https&se=2020-08-12T00%3A01%3A08Z&rscl=x-e2eid-07ee394c-3dec4f3a-8c6ce55b-973c3849-session-07ee394c-3dec4f3a-8c6ce55b-973c3849&rscd=attachment%3B%20filename%3D%22example3-0.1.0-py3-none-any.whl%22" in the cache
  No cache entry available
  Starting new HTTPS connection (1): ajhvsblobprodcus363.blob.core.windows.net:443
  https://ajhvsblobprodcus363.blob.core.windows.net:443 "GET /b-0b71cd34f9c34172994c8b112c0efbc5/DBCE858FD979095ABFDDD6486916184A6D96809832BC940EDF646466AA55BB4D00.blob?sv=2019-02-02&sr=b&si=1&sig=CLumZkVQO3JWN3JIWgGeIvjOzsJ7dGughsR4UJwXkRA%3D&spr=https&se=2020-08-12T00%3A01%3A08Z&rscl=x-e2eid-07ee394c-3dec4f3a-8c6ce55b-973c3849-session-07ee394c-3dec4f3a-8c6ce55b-973c3849&rscd=attachment%3B%20filename%3D%22example3-0.1.0-py3-none-any.whl%22 HTTP/1.1" 200 1002
  Downloading https://pkgs.dev.azure.com/chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl (1.0 kB)
  Updating cache with response from "https://ajhvsblobprodcus363.blob.core.windows.net/b-0b71cd34f9c34172994c8b112c0efbc5/DBCE858FD979095ABFDDD6486916184A6D96809832BC940EDF646466AA55BB4D00.blob?sv=2019-02-02&sr=b&si=1&sig=CLumZkVQO3JWN3JIWgGeIvjOzsJ7dGughsR4UJwXkRA%3D&spr=https&se=2020-08-12T00%3A01%3A08Z&rscl=x-e2eid-07ee394c-3dec4f3a-8c6ce55b-973c3849-session-07ee394c-3dec4f3a-8c6ce55b-973c3849&rscd=attachment%3B%20filename%3D%22example3-0.1.0-py3-none-any.whl%22"
  Caching due to etag
  Added example3 from https://pkgs.dev.azure.com/chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl#sha256=ff49370bdba639695bf4d3e96b80b6b0e8a3c65011c1cef658a3885c7d913c58 to build tracker '/tmp/user/1000/pip-req-tracker-gvbk9pnb'
  Removed example3 from https://pkgs.dev.azure.com/chrahunt/0be4dbf5-2e6a-4329-b457-6bfc3813daf9/_packaging/40f8bcae-0cca-47f2-afd9-ef0739ae93db/pypi/download/example3/0.1/example3-0.1.0-py3-none-any.whl#sha256=ff49370bdba639695bf4d3e96b80b6b0e8a3c65011c1cef658a3885c7d913c58 from build tracker '/tmp/user/1000/pip-req-tracker-gvbk9pnb'
Installing collected packages: example3

Successfully installed example3-0.1.0
Removed build tracker: '/tmp/user/1000/pip-req-tracker-gvbk9pnb'

This doesn't show the behavior I'm concerned with (a redirect instead of a 401, as in #8103 (comment)), so it's a little reassuring.

I think including just the first commit is still less of a risk.

pradyunsg · 2020-08-11T03:34:33Z

If we go that route we may want to confirm that there are no plans to offer private repos on PyPI anytime soon.

Hah, I can confirm this. PyPI runs on donated infrastructure, so trying to do something like this (which only makes sense if you have paying customers) would likely result in it losing access to that infrastructure.

pradyunsg · 2020-08-11T10:12:29Z

Alrighty! #8744 is merged. 20.2.2 coming up soon! :)

ssbarnea · 2020-09-08T10:47:35Z

Any chance to see this shipped? Current behavior creates deadlocks.

uranusjr · 2020-09-09T05:41:19Z

Hmm, 20.2.3 was released without this change. Not sure if it’s intended or not @pradyunsg

pradyunsg · 2020-09-09T06:04:07Z

We broke out #8744, which was released in 20.2.2. Is there something else that I'm missing?

Things have changed since!

uranusjr · 2020-10-10T15:08:50Z

I added this to 20.3. Rebasing needed!

zooba

Apologies for the slow reply, I'm trying to make more of an effort to dredge through my GH notifications.

I think this is an overall improvement, and don't have any concerns wrt the keyring integration or artifacts-keyring compat.

zooba · 2020-11-06T21:47:15Z

src/pip/_internal/network/auth.py

@@ -110,7 +112,7 @@ def _get_index_url(self, url):
        return None

    def _get_new_credentials(self, original_url, allow_netrc=True,
-                             allow_keyring=True):
+                             allow_keyring=False):


FWIW, Azure DevOps should return 401 now, but it's filtered on user agents to make sure that people who get given the URL land on a useful page. So you can see it through an actual pip install, but likely not if you curl directly.

zooba · 2020-11-06T21:56:47Z

src/pip/_internal/network/auth.py

        # Prompt the user for a new username and password
-        username, password, save = self._prompt_for_password(parsed.netloc)
+        save = False
+        if not username or not password:


From the last three points:

I think this is the correct behaviour. Handling redirects feels like goodness (e.g. I can bit.ly an index URL), and if a redirect turns out to be malicious, we don't want to pass along legitimate credentials to a different site

Unavoidable, probably? But we're in a failure case by then anyway, so an extra request is not the end of the world.

Correct, though if _get_new_credentials can map it back to a user-specified index url that has embedded credentials, those will be used

It is complicated, but I think this all lines up.

For the single-part credential issue, we probably want if not username and not password: - assuming that if we got a partial credential that we should still try it. _get_new_credentials has the logic for trying to turn a partial credential into a full one.

tests/unit/test_network_auth.py

calumapplepie · 2020-12-03T04:51:27Z

What's the status on the PR? The Debian freeze is approaching, and ideally the pip version included will be fully functional.

pradyunsg · 2020-12-29T19:04:20Z

@hroncok Would you be able to make time before pip 21.0 to rebase this PR? It'd be great if we could include this in that.

hroncok · 2020-12-29T19:24:33Z

Rebased. But I'm not sure I am capable of incorporating all the feedback from @zooba.

hroncok · 2020-12-29T19:32:35Z

CI thinks there's something wrong with the news fragment, but I fail to understand it :(

uranusjr · 2020-12-29T20:10:25Z

It is looking for a .rst suffix. Towncrier works fine without it, but pip's check mandates.

hroncok · 2020-12-29T20:16:24Z

Thanks! File renamed.

pradyunsg · 2020-12-30T14:05:51Z

I think this looks OK. If @zooba agrees, I think we can go ahead and merge this? :)

zooba · 2021-01-04T15:42:44Z

My only remaining comment is that we will still prompt for credentials if keyring provides a username or password but not both, even though that may be legitimate. Switching the "or" in auth:262 to an "and" should fix that, but I can't be 100% sure that it's better.

Given that we don't reuse any partial information in the prompt, I'm inclined to say we should (log a message first and then) send the partial credential. If it's just a PAT, there's no good way for a user to reproduce that at the prompt.

hroncok · 2021-01-04T16:10:15Z

Switching the "or" in auth:262 to an "and" should fix that, but I can't be 100% sure that it's better.

Happy to do that if that's the consensus.

pradyunsg · 2021-01-04T16:26:34Z

Go ahead!

If someone complains, I'll likely @ mention both of you for help. 🙃

Fixes pypa#8090

hroncok · 2021-01-04T16:48:45Z

Done. https://github.com/pypa/pip/compare/e586bb82bb37cdf1b73703adc00dc804a81fb3f1..886275de2d7f92823c812fd0b89a402560c357df

uranusjr · 2021-02-18T10:04:37Z

Let’s do this.

hroncok mentioned this pull request Aug 3, 2020

pip + twine installed: pip attempts to continuously create and use a "keyring" #8090

Closed

hroncok force-pushed the keyring_madness branch from 6ddd9ed to 43213b1 Compare August 3, 2020 10:34

pradyunsg previously approved these changes Aug 7, 2020

View reviewed changes

pradyunsg added this to the 20.2.2 milestone Aug 7, 2020

chrahunt reviewed Aug 7, 2020

View reviewed changes

uranusjr mentioned this pull request Aug 10, 2020

pip 20.2 release (Q3 2020) #8511

Closed

hroncok mentioned this pull request Aug 10, 2020

When one keyring attempt fails, don't bother with more #8744

Merged

pradyunsg removed this from the 20.2.2 milestone Aug 11, 2020

pradyunsg mentioned this pull request Aug 30, 2020

Pip install block waiting forever for a keyring to unlock #7883

Closed

pradyunsg mentioned this pull request Sep 7, 2020

Document how to disable keyring for users who might want to #6773

Open

uranusjr added this to the 20.3 milestone Oct 10, 2020

pradyunsg removed this from the 20.3 milestone Oct 26, 2020

pradyunsg mentioned this pull request Oct 28, 2020

Every single command from pip runs super slow #8485

Closed

pradyunsg added the C: keyring Related to pip's keyring integration label Nov 5, 2020

zooba approved these changes Nov 6, 2020

View reviewed changes

hroncok force-pushed the keyring_madness branch from 43213b1 to 2ba3760 Compare December 29, 2020 19:23

hroncok force-pushed the keyring_madness branch from 2ba3760 to 1ca4cbd Compare December 29, 2020 19:26

hroncok force-pushed the keyring_madness branch from 1ca4cbd to e586bb8 Compare December 29, 2020 20:16

uranusjr approved these changes Dec 30, 2020

View reviewed changes

pradyunsg approved these changes Dec 30, 2020

View reviewed changes

Only query the keyring for URLs that actually trigger error 401

886275d

Fixes pypa#8090

hroncok force-pushed the keyring_madness branch from e586bb8 to 886275d Compare January 4, 2021 16:48

uranusjr merged commit 62af956 into pypa:master Feb 18, 2021

hroncok deleted the keyring_madness branch February 18, 2021 17:04

jaraco mentioned this pull request Feb 24, 2021

Keyring prevent some package uninstall #8443

Closed

ffissore mentioned this pull request Apr 26, 2021

Keyring auth stopped working since 21.1 #9870

Closed

1 task

sbidoul mentioned this pull request Apr 26, 2021

Requiring keyring authentication when repository returns 403 #9871

Closed

github-actions bot locked as resolved and limited conversation to collaborators Oct 2, 2021

Don't overuse the keyring #8687

Don't overuse the keyring #8687

Conversation

hroncok commented Aug 3, 2020 • edited Loading

hroncok commented Aug 5, 2020

pradyunsg left a comment • edited Loading

Choose a reason for hiding this comment

pradyunsg commented Aug 7, 2020

uranusjr commented Aug 7, 2020 • edited Loading

chrahunt Aug 7, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrahunt Aug 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pradyunsg commented Aug 10, 2020

hroncok commented Aug 10, 2020

pradyunsg commented Aug 10, 2020

pfmoore commented Aug 10, 2020

pradyunsg commented Aug 10, 2020

hroncok commented Aug 10, 2020

chrahunt commented Aug 10, 2020

chrahunt commented Aug 11, 2020

pradyunsg commented Aug 11, 2020

pradyunsg commented Aug 11, 2020

ssbarnea commented Sep 8, 2020

uranusjr commented Sep 9, 2020

pradyunsg commented Sep 9, 2020

uranusjr commented Oct 10, 2020

zooba left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

calumapplepie commented Dec 3, 2020

pradyunsg commented Dec 29, 2020

hroncok commented Dec 29, 2020

hroncok commented Dec 29, 2020

uranusjr commented Dec 29, 2020

hroncok commented Dec 29, 2020

pradyunsg commented Dec 30, 2020

zooba commented Jan 4, 2021

hroncok commented Jan 4, 2021

pradyunsg commented Jan 4, 2021

hroncok commented Jan 4, 2021

uranusjr commented Feb 18, 2021

hroncok commented Aug 3, 2020 •

edited

Loading

pradyunsg left a comment •

edited

Loading

uranusjr commented Aug 7, 2020 •

edited

Loading

chrahunt Aug 7, 2020 •

edited

Loading

chrahunt Aug 8, 2020 •

edited

Loading