lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Jun 2023 15:23:08 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Jonathan Corbet <corbet@....net>,
        Íñigo Huguet <ihuguet@...hat.com>,
        ojeda@...nel.org, danny@...ag0n.dev
Cc:     masahiroy@...nel.org, jgg@...dia.com, linux-kernel@...r.kernel.org,
        joe@...ches.com, linux@...musvillemoes.dk, willy@...radead.org,
        mailhol.vincent@...adoo.fr
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting


On 09/06/2023 09:50, Jonathan Corbet wrote:
> Íñigo Huguet <ihuguet@...hat.com> writes:
> 
>> EditorConfig is a specification to define the most basic code formatting
>> stuff, and it's supported by many editors and IDEs, either directly or
>> via plugins, including VSCode/VSCodium, Vim, emacs and more.
>>
>> It allows to define formatting style related to indentation, charset,
>> end of lines and trailing whitespaces. It also allows to apply different
>> formats for different files based on wildcards, so for example it is
>> possible to apply different configs to *.{c,h}, *.py and *.rs.
>>
>> In linux project, defining a .editorconfig might help to those people
>> that work on different projects with different indentation styles, so
>> they cannot define a global style. Now they will directly see the
>> correct indentation on every fresh clone of the project.
>>
>> See https://editorconfig.org
>>
>> Co-developed-by: Danny Lin <danny@...ag0n.dev>
>> Signed-off-by: Danny Lin <danny@...ag0n.dev>
>> Signed-off-by: Íñigo Huguet <ihuguet@...hat.com>
> 
> So I must confess to still being really nervous about installing a file
> that will silently reconfigure the editors of everybody working on the
> kernel source; I wish there were a straightforward way to do this as an
> opt-in thing.  We're talking about creating a flag-day behavioral change
> for, potentially, thousands of kernel developers.  Something tells me
> that we might just hear from a few of them.
> 
> I wonder if we should, instead, ship a file like this as something like
> Documentation/process/editorconfig, then provide a "make editorconfig"
> command that installs it in the top-level directory for those who want
> it?
> 
> Or perhaps I'm worrying too much?

This is a legitimate concern. :)

A safe approach would be to rename the ".editorconfig" file to something 
like ".editorconfig.default" and create ".editorconfig" symlinks in all 
(parent) directories where enforcing this rules don't change anything 
because the children files are already correctly formatted. Again, a 
script (provided in another patch) to check and potentially update such 
links would be useful.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ