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]
Message-ID: <CACT4oudDKALZ0ZQPrOj2o3cRBRoaGMK_S+hQx-q4ENfv4UCtnQ@mail.gmail.com>
Date:   Thu, 15 Jun 2023 08:35:30 +0200
From:   Íñigo Huguet <ihuguet@...hat.com>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        Jonathan Corbet <corbet@....net>, ojeda@...nel.org,
        danny@...ag0n.dev, masahiroy@...nel.org, jgg@...dia.com,
        linux-kernel@...r.kernel.org, joe@...ches.com,
        linux@...musvillemoes.dk, willy@...radead.org
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Thu, Jun 15, 2023 at 4:40 AM Vincent MAILHOL
<mailhol.vincent@...adoo.fr> wrote:
>
> On Wed. 14 Jun. 2023 at 22:04, Íñigo Huguet <ihuguet@...hat.com> wrote:
> > On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL <mailhol.vincent@...adoo.fr> wrote:
> > > On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@...hat.com> wrote:
>
> (...)
>
> > > > Right now I see 2 possibilities:
> > > > - Provide an .editorconfig.default so those that want to use it, can
> > > > do it. But I wouldn't mess with cherry-picking directories that
> > > > already complies and those that don't, just the developer chooses to
> > > > use it or not, and that's all.
> > > > - Provide an .editorconfig directly, and those that don't want to use
> > > > it, either disable it in their editors or manually delete the file.
> > > >
> > > > Please tell me what approach you prefer.
> > >
> > > Personally, I vote for the latter. My honest opinion is that we are
> > > putting too much consideration into the risk of rejections.
> >
> > I completely agree.
> >
> > > Íñigo previously stated that editors such as Kate can not opt out. I
> > > think that the reason is simply that no one has complained about it so
> > > far. I did some research on the internet with the keyword "kate
> > > disable editorconfig", and nothing  relevant appeared. A deeper
> > > research made me found this:
> >
> > I have not "complained", but I have filled a request just today, that
> > I think won't reach far: https://bugs.kde.org/show_bug.cgi?id=471008
>
> Wow! That's a lot of investment on your side. Clearly, there is no
> appetite from the maintainers. But if something needs to be done
> (which I doubt), I think it should be on the editor's side rather than
> on the project using that .editorconfig file.
>
> > >   KatePart has support for reading configurations from
> > >   .editorconfig files, when the editorconfig library is
> > >   installed. KatePart automatically searches for a .editorconfig
> > >   whenever you open a file. It gives priority to .kateconfig
> > >   files, though.
> > >
> > > source: https://docs.kde.org/stable5/en/kate/katepart/config-variables.html
> > >
> > > So it appears that for Kate, installing the editorconfig lib is a
> > > prerequisite. I think it falls in the opt-in category.
> >
> > I'm not 100% sure, but I think that this is a requisite at build time.
> > So unless you build Kate from source, it will be built-in without
> > opt-out choice.
>
> It seems you are right. On Ubuntu, the "kate" package actually depends
> on "libeditorconfig0", so indeed, that's a hard dependency. My bad.
>
> That said, on source based distribution, it should be configurable.
> Taking gentoo as an example, you get an editorconfig USEFLAG which
> allows to choose whether or not you enable editorconfig during the
> compilation:
>
>   https://packages.gentoo.org/packages/kde-frameworks/ktexteditor
>
> I continued my investigation. Here is the commit which adds
> editorconfig to ktexteditor (used by kate):
>
>   https://github.com/KDE/ktexteditor/commit/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e
>
> Looking at what the code does, it first walk through the absolute path
> in reverse and if it finds a .kateconfig file, it does an early
> return:
>
>   https://github.com/KDE/ktexteditor/blob/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e/src/document/katedocument.cpp#L2578
>
> This should act as a kill switch. Not tested, but adding a .kateconfig
> seems like a valid opt out method. This is consistent with the
> paragraph I quoted in my previous message:
>
>   It gives priority to .kateconfig files, though.
>
> Problem solved?

Very good catch. I have tried and adding an empty .kateconfig file
makes that .editorconfig is ignored. For me this is a simple enough
workaround. We can document it as a comment in the top of
.editorconfig file.

>
> > > Is there really an editor with default opt-in and no options to
> > > opt-out? I doubt...
> >
> > Kate is the only one I have seen so far, but it's difficult to know.
> >
> > > I really think we should have the .editorconfig at the root and for
> > > the rare edge cases where the user really wants to opt-out, I
> > > sincerely believe that there will be solutions. I have seen many
> > > projects using it and I do not recall push backs or complaints.
>


-- 
Íñigo Huguet

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ