Enforce token encryption as plaintext tokens are no longer being used to optimize queries with CreatePipelineService
As a follow up from #326475 (comment 557714271), @mbobin wrote this up as a way to further optimize some of our SQL queries in Ci::CreatePipelineService
It took a long while to complete but here are the results: https://console.postgres.ai/shared/236d2859-a90c-4273-b759-c18abdbf1ed2
SELECT "ci_builds".* FROM "ci_builds" WHERE "ci_builds"."type" = 'Ci::Build' AND "ci_builds"."token" IS NOT NULL AND > >(created_at > '2020-04-21 09:13:55.747745')
(actual time=64889855.136..64889855.137 rows=0 loops=1)
There are no builds with plaintext tokens created in the last year, so we are good to enforce token encryption.
@cheryl.li
as to removing them entirely, I think it would be a weight of somewhere between 3 to 5 because we would need to refactor how the token is generated and recompute the tokens for the failed inserts. But we need to be careful here because this module is also used by other entities.I wonder what is the probability of hitting such edge case. Perhaps it is not very likely. Can we get some data about it?
@grzesiek
I think the entropy for our tokens is118
, but I don't know how to interpret it, how many tokens do we need to generate before a collision. Perhaps we could nullify the tokens after the job completes since we require them to be running when authentication via tokens.🤔 token_length = 20 possible_chars = ("a".."z").to_a + ("A".."Z").to_a + (1..9).to_a + %w(- _) - %w(l I O) Math.log(possible_chars.length)/Math.log(2) * token_length # => 118.13781191217038