On Fri, Feb 16, 2024 at 09:27:48PM +0100, Jiri Kosina wrote:
>
> Now that you have played the distro card (thanks!) here, let me just copy
> my comment from LWN where someone suggested "well, it's easy, it's the job
> of the [paid] distros to do the triage" ...
>
> The problem is, that with thi
On Tue, Jun 04, 2019 at 01:48:35PM -0600, Jonathan Corbet wrote:
> +
> +Maintaining a subsystem, as a general rule, requires a familiarity with
> the +Git source-code management system. Git is a powerful tool with a lot
> of +features; as is often the case with such tools, there are right and
> wr
On Tue, Jun 04, 2019 at 01:08:37PM -0600, Jonathan Corbet wrote:
> On Sat, 1 Jun 2019 11:42:48 -0400
> "Theodore Ts'o" wrote:
>
> > Finally, I'm bit concerned about anything which states absolutes,
> > because there are people who tend to be real st
On Thu, May 30, 2019 at 01:53:17PM -0600, Jonathan Corbet wrote:
> +Rebasing
> +
> +
> +"Rebasing" is the process of changing the history of a series of commits
> +within a repository. At its simplest, a rebase could change the starting
> +point of a patch series from one point to another.
On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote:
> On 5/11/19 10:33 AM, Theodore Ts'o wrote:
> > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> >> However, the reply is incorrect. Kselftest in-kernel tests (which
> >> is the context
On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> However, the reply is incorrect. Kselftest in-kernel tests (which
> is the context here) can be configured as built in instead of as
> a module, and built in a UML kernel. The UML kernel can boot,
> running the in-kernel tests before
On Mon, Mar 18, 2019 at 09:37:28PM -0500, Vijay Chidambaram wrote:
> For new folks on the thread, I'm Vijay Chidambaram, prof at UT Austin
> and Jayashree's advisor. We recently developed CrashMonkey, a tool for
> finding crash-consistency bugs in file systems. As part of the
> research effort, we
On Thu, Mar 14, 2019 at 09:19:03AM +0200, Amir Goldstein wrote:
> > > +ext4
> > > +-
> > > +fsync(file) : Ensures that a newly created file's directory entry is
> > > +persisted (no need to explicitly persist the parent directory). However,
> > > +if you create multiple names of the file (hard
On Wed, Jan 17, 2018 at 02:38:59PM +, André Draszik wrote:
> > > [...]
> >
> > Please be very clear about exactly what security properties are achieved
> > by
> > using encrypted-keys.
>
> I've left out all of this in the updated documentation, as any such
> information should probably be in
On Wed, Jan 10, 2018 at 02:47:19AM +0200, Bob Bib wrote:
> Hello,
>
> just curious,
> what's the official meaning of the "CRNG" acronym (e. g., in [1])?
>
> Some searching suggests that "C[S]RNG"
> means "cryptographic[-strength] random number generator".
> [1]
> https://git.kernel.org/pub/scm/l
On Fri, Sep 08, 2017 at 05:15:12PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Perhaps long overdue, add a documentation file for filesystem-level
> encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
> directory. The new file is based loosely on the latest version of the
> "E
On Sat, Sep 16, 2017 at 01:48:37PM +0200, Pavel Machek wrote:
> Fix little inconsistencies in Documentation: make case and spacing
> match surrounding text.
>
> Signed-off-by: Pavel Machek
> Reviewed-by: Darrick J. Wong
Applied, thanks.
- Ted
--
To unsub
On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
> > If *no* applications care whether the filenames are encrypted or not, sure.
> > But are you absolutely sure that no applications care? How do you know?
> > And what
> > is the advantage of not encrypting the filenames anyway? It is
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote:
>
> I think AE is the only good solution for this, File-name encryption at
> this stage won't solve any kind of Evil Maid attack, (as it was quoted
> somewhere else in ML).
AE doesn't help at all against the Evil Maid attack, since the
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote:
>
>
> > +fscrypt is not guaranteed to protect confidentiality or authenticity
> > +if an attacker is able to manipulate the filesystem offline prior to
> > +an authorized user later accessing the filesystem.
>
> How does fscrypt / Andr
On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote:
> > +Key hierarchy
> > +=
> > +
> > +Master Keys
> > +---
> > +
> > +Userspace should generate master keys either using a cryptographically
> > +secure random numb
On Thu, May 18, 2017 at 05:15:17PM -0400, Konstantin Ryabitsev wrote:
>
> I had someone ask me today whether https://www.kernel.org/doc/html/latest/
> is covered by GNU GPL or GNU FDL, and honestly I wasn't sure, as there is
> actually no clear indication. There's places where FDL is listed
> (htt
On Sun, Mar 26, 2017 at 11:25:50PM +0900, SeongJae Park wrote:
> As ftp.kernel.org is closed [0], this commit fixes dead URLs in
> documents to use www.kernel.org instead.
>
> [0] https://www.kernel.org/shutting-down-ftp-services.html
>
> Signed-off-by: SeongJae Park
Acked
On Thu, Nov 17, 2016 at 12:07:15PM +0100, Arnd Bergmann wrote:
> [adding Linus for clarification]
>
> I understood the concern as being about binary files that you cannot
> modify with classic 'patch', which is a separate issue.
I think the other complaint is that the image files aren't "source"
On Tue, Oct 18, 2016 at 07:37:34AM -0600, Jonathan Corbet wrote:
> On Tue, 18 Oct 2016 06:30:48 +0200
> Markus Heiser wrote:
>
> > One Silly request of mine:
> >
> > Is there a chance moving "./Documentation" to something shorter
> > like "./doc"? Even with "Text completion" (in Emacs [1]), IMO
On Fri, Apr 15, 2016 at 02:29:52PM +0100, Richard W.M. Jones wrote:
>
> The use case is that we have endless trouble with people setting weird
> umask() values (usually on the grounds of "security"), and then
> everything breaking. I'm on the hook to fix these. We'd like to add
> debugging to ou
On Mon, Feb 15, 2016 at 03:52:31PM -0800, Daniel Walker wrote:
> >>We need it to determine accurately what the free memory in the
> >>system is. If you know where we can get this information already
> >>please tell, we aren't aware of it. For instance /proc/meminfo isn't
> >>accurate enough.
>
> A
22 matches
Mail list logo
