https://git.schokokeks.org/derivepassphrase.git/tree/1e5d605177a2f2a4441c99ca1515efaa55449697Recent commits to derivepassphrase.git (1e5d605177a2f2a4441c99ca1515efaa55449697)2024-06-08T19:06:56+02:00tag:gitlist.org,2012:commit/1e5d605177a2f2a4441c99ca1515efaa55449697Fix character set subtraction logic2024-06-08T19:06:56+02:00Marco Riccim@the13thletter.info
<pre>Use a static method, and treat both the original character set and the
subtracted character set as sets (i.e. no repetitions allowed).
</pre>
tag:gitlist.org,2012:commit/407bbddff031476549ae018bbe5de566a3b1f738Fix repeated character detection logic in passphrase generation2024-06-08T19:06:56+02:00Marco Riccim@the13thletter.info
<pre>The prototype implementation is based off a JavaScript program, and is
clumsy to read and hard to verify if translated directly to Python. (It
also interacts badly with type checking.) Rewrite the check in
a pythonic manner, from scratch, that is much easier to verify.
</pre>
tag:gitlist.org,2012:commit/eb649f6489030b7e1ce4dc764713df4165725be5Use neutral arguments in `Vault.create_hash` signature2024-06-08T19:06:56+02:00Marco Riccim@the13thletter.info
<pre>Currently, when generating a passphrase from an SSH key signature,
`derivepassphrase.Vault.create_hash` requires the user to know the role
of the `key` and `message` arguments themselves; in particular, it
requires the user to add the vault UUID to the message themselves. The
fact that the vault UUID is added to the hashing input is an
implementation detail, as should be the fact that one of the arguments
is a key and the other is a salt value to a key-derivation function. Put
these details only into the docstring's description section, not the
argument names; rename them to `phrase` and `service`, respectively.
</pre>
tag:gitlist.org,2012:commit/a9eb9aefb6a0d9c5555e16141435664382cb1cbeAdd test for service name byte string types2024-06-08T19:06:56+02:00Marco Riccim@the13thletter.info
<pre></pre>
tag:gitlist.org,2012:commit/5403acefe8c2e2872ab3f884401115ab2419caf5Add unit tests, both new and doctest-converted2024-05-21T00:40:13+02:00Marco Riccim@the13thletter.info
<pre>doctests which are not pedagogical, but unit test-y in nature, are
better off rewritten as proper unit tests.
</pre>
tag:gitlist.org,2012:commit/50749ca2a633eb4d8275de7e9dff586417c79af6Fix numerous argument type or range errors2024-05-21T00:40:13+02:00Marco Riccim@the13thletter.info
<pre></pre>
tag:gitlist.org,2012:commit/474934db470dda3de512b98eba629ba1a835ded5Add prototype implementation2024-05-19T00:24:09+02:00Marco Riccim@the13thletter.info
<pre>Plumbing only; there is no user interface yet. The code type-checks,
but has been only superficially tested for correctness in the Python
interactive prompt. API documentation is written, but probably also
of "first draft" quality, and other kinds of documentation (usage,
design) are missing completely.
</pre>
tag:gitlist.org,2012:commit/16c26e1d7207f75f79d2f342bfa87913fa09a84dImport initial project files2024-05-05T11:57:20+02:00Marco Riccim@the13thletter.info
<pre></pre>