<feed xmlns='http://www.w3.org/2005/Atom'>
<title>fscrypt.git/cli-tests/t_v1_policy.sh, branch v0.3.6</title>
<subtitle>Go tool for managing Linux filesystem encryption
</subtitle>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/'/>
<entry>
<title>cli-tests: account for protojson whitespace randomization</title>
<updated>2022-08-18T06:10:56+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-08-18T05:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=afad6a1e0521e52dfaffe937ecab2515a76b8134'/>
<id>afad6a1e0521e52dfaffe937ecab2515a76b8134</id>
<content type='text'>
Annoyingly, for JSON formatting protojson randomly selects a spacing
method (one space or two spaces) depending on a hash of some sections of
the Go binary, to discourage depending on its output being stable.  This
breaks some checks in the CLI tests of the contents of fscrypt.conf and
the output of 'fscrypt status'.  As there doesn't appear to be a
straightforward alternative currently, for now just update the tests to
take into consideration the possible extra space.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Annoyingly, for JSON formatting protojson randomly selects a spacing
method (one space or two spaces) depending on a hash of some sections of
the Go binary, to discourage depending on its output being stable.  This
breaks some checks in the CLI tests of the contents of fscrypt.conf and
the output of 'fscrypt status'.  As there doesn't appear to be a
straightforward alternative currently, for now just update the tests to
take into consideration the possible extra space.
</pre>
</div>
</content>
</entry>
<entry>
<title>cli-tests/t_v1_policy: clean up user keyrings at end of test</title>
<updated>2020-06-13T17:06:15+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-06-13T17:06:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=c39fc85f8045bb24f773a3eb5dee7738cdc4339f'/>
<id>c39fc85f8045bb24f773a3eb5dee7738cdc4339f</id>
<content type='text'>
The test user's user keyring is still linked into root's user keyring at
the end of the test.  This is making the test flaky, as there is a
failure that only occurs the first time it is run.  Fix the test to
restore the initial state.  This makes it consistently fail (to be fixed
by the next commit).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The test user's user keyring is still linked into root's user keyring at
the end of the test.  This is making the test flaky, as there is a
failure that only occurs the first time it is run.  Fix the test to
restore the initial state.  This makes it consistently fail (to be fixed
by the next commit).
</pre>
</div>
</content>
</entry>
<entry>
<title>Try to detect incomplete locking of v1-encrypted directory</title>
<updated>2020-05-09T22:16:13+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:17:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=de51add609bc74b7247ec4776bd694abbea24a45'/>
<id>de51add609bc74b7247ec4776bd694abbea24a45</id>
<content type='text'>
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.

Instead, implement a heuristic where we check whether a subdirectory can
be created.  If yes, then the directory must not be fully locked.

Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.

Resolves https://github.com/google/fscrypt/issues/215
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.

Instead, implement a heuristic where we check whether a subdirectory can
be created.  If yes, then the directory must not be fully locked.

Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.

Resolves https://github.com/google/fscrypt/issues/215
</pre>
</div>
</content>
</entry>
<entry>
<title>cli-tests: add t_v1_policy</title>
<updated>2020-05-09T21:04:47+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=b13bfeef21c18302dcb31f7fb6d354da9a5a567b'/>
<id>b13bfeef21c18302dcb31f7fb6d354da9a5a567b</id>
<content type='text'>
Test using v1 encryption policies (deprecated).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Test using v1 encryption policies (deprecated).
</pre>
</div>
</content>
</entry>
</feed>
