~bitfehler

https://bitfehler.net

Trackers

~bitfehler/vomit

Last active 9 months ago

~bitfehler/names.sr.ht

Last active 11 months ago

#370 uploadArtifact() returns Artifact with obviously fake URL 2 months ago

Comment by ~bitfehler on ~sircmpwn/git.sr.ht

Two things:

  1. This seems to be a misunderstanding. The URL has always been the internal storage URL, it is not meant for outside use. AFAIU the public URL of an artifact is predetermined (https://git.sr.ht/~<user>/<repo>/refs/download/<tag>/<filename>), hence there is no need to return it (besides potentially convenience?). Admittedly, this is documented neither for the old nor the new API, so I'll submit a patch at least for the new API to do so.

  2. That said, this is indeed currently broken in GraphQL, because unlike in the old API, the GraphQL resolver does not add artifacts/<user>/<repo> to the prefix. I'll submit a patch for that as well, but it's unfortunately not quite trivial, so I'll need some time to prepare a test environment with repos and artifacts.

#201 API: remove queries by ID 4 months ago

Ticket created by ~bitfehler on ~sircmpwn/lists.sr.ht

  • user(id: Int!) should be removed
  • mailingList(id: Int!) should be removed
  • email(id: Int!) should be removed, but message(messageID: String!) must be fixed first (angle brackets and potential comments removed from database)
  • patchset(id: Int!) should be replaced by patchset(messageID: String!)

#187 openpgp: invalid argument: cannot encrypt a message to key id 78a39b4a078e6c06 because it has no valid encryption keys 7 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

i could take a look at this if you can maybe provide a bit more context?

#193 GraphQL query error: too many colons in address (IPv6-related) 7 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

This was fixed in https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/2fa9543 and can be closed.

#190 #188 should not have crashed the API daemon 8 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

So yeah, sorry, but I cannot reproduce this. There must have been some circumstance leading to this that got lost in translation. We should probably close this ticket and create a new one with new information if this ever happens again.

#193 GraphQL query error: too many colons in address (IPv6-related) 8 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

So, this was fixed in a different place in meta.sr.ht before: https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/6a64ac6a, but was missed elsewhere: https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/item/api/graph/schema.resolvers.go#L737

Which begs the question: should we maybe put s/t in the middleware that always strips the port? No assumptions can be made about it being present, anyways.

WDYT, ~sircmpwn?

#193 GraphQL query error: too many colons in address (IPv6-related) 8 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

I'll look into this, the cause is obvious, not sure how easy the fix is, though

#194 Store PGP key expiration date in database 8 months ago

Comment by ~bitfehler on ~sircmpwn/meta.sr.ht

Proposed plan:

Keys can have an expiration date or not -> DB column would be nullable "timestamp without time zone".

Default would be NULL for all existing keys, which would then mean both "does not expire" and "not known if it expires".

Question: how to migrate existing keys? I see two options:

  1. Simply start computing the date for new keys, letting (much) time take care of it
  2. Make a job to compute the expiration date for all keys with a "created" date before the feature was put in place

Note that option 2 would either require that job to maintain some state, or we'd need to keep track in the database whether or not the keys expiration date has been computed yet. But I don't see a clean way to also store this information. We could use some sort of magic date (e.g $MAX_DATE for "never expires", whatever that might be). But that probably just spells trouble down the road?

#194 Store PGP key expiration date in database 8 months ago

Ticket created by ~bitfehler on ~sircmpwn/meta.sr.ht

It would be great to be able to inform users if their uploaded PGP key is expired or about to expire.

The expiration date of a key is expensive to compute and doesn't change unless the key material is updated. Hence, compute it during key upload and store it in the database.

#2 Implement `vmt sync` 8 months ago

Comment by ~bitfehler on ~bitfehler/vomit

Now that https://git.sr.ht/~bitfehler/vomit-sync/ is a thing, vmt sync should be implemented using that.