On Feb 18, 2021, at 4:21 PM, Daniel Rosenberg wrote:
>
> On Wed, Feb 17, 2021 at 2:48 PM Andreas Dilger wrote:
>>
>> On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote:
>>>
>>> The problem is in how the space after the filename in a directory is
>>> encoded. The dirdata format is (mildly)
On Wed, Feb 17, 2021 at 03:48:39PM -0700, Andreas Dilger wrote:
> It would be possible to detect if the encrypted/casefold+dirdata
> variant is in use, because the dirdata variant would have the 0x40
> bit set in the file_type byte. It isn't possible to positively
> identify the "raw" non-dirdata
On Wed, Feb 17, 2021 at 2:48 PM Andreas Dilger wrote:
>
> On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote:
> >
> > On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote:
> >> I'm not sure what the conflict is, at least format-wise. Naturally,
> >> there would need to be some work to
On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote:
>
> On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote:
>> I'm not sure what the conflict is, at least format-wise. Naturally,
>> there would need to be some work to reconcile the two patches, but my
>> patch only alters the format
On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote:
> I'm not sure what the conflict is, at least format-wise. Naturally,
> there would need to be some work to reconcile the two patches, but my
> patch only alters the format for directories which are encrypted and
> casefolded, which
I'm not sure what the conflict is, at least format-wise. Naturally,
there would need to be some work to reconcile the two patches, but my
patch only alters the format for directories which are encrypted and
casefolded, which always must have the additional hash field. In the
case of dirdata along
On Tue, Feb 09, 2021 at 08:03:10PM -0700, Andreas Dilger wrote:
> Depending on the size of the "escape", it probably makes sense to move
> toward having e2fsck migrate from the current mechanism to using dirdata
> for all deployments. In the current implementation, tools don't really
> know for
On Feb 9, 2021, at 4:22 PM, Theodore Ts'o wrote:
>
> On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote:
>> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
>>>
>>> It looks like this change will break the dirdata feature, which is similarly
>>> storing a data field
On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote:
> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
> >
> > It looks like this change will break the dirdata feature, which is similarly
> > storing a data field beyond the end of the dirent. However, that feature
> >
On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
>
> It looks like this change will break the dirdata feature, which is similarly
> storing a data field beyond the end of the dirent. However, that feature also
> provides for flags stored in the high bits of the type field to
This adds support for encryption with casefolding.
Since the name on disk is case preserving, and also encrypted, we can no
longer just recompute the hash on the fly. Additionally, to avoid
leaking extra information from the hash of the unencrypted name, we use
siphash via an fscrypt v2 policy.
11 matches
Mail list logo
