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: <87d0kvvkej.fsf@codeaurora.org>
Date:   Mon, 06 May 2019 15:26:28 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Victor Bravo <1905@...blk.com>,
        Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        "David S. Miller" <davem@...emloft.net>,
        linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        brcm80211-dev-list@...ress.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2

Hans de Goede <hdegoede@...hat.com> writes:

> If we're going to do some filtering, then I suggest we play it safe and also
> disallow other chars which may be used as a separator somewhere, specifically
> ':' and ','.
>
> Currently upstream linux-firmware has these files which rely on the DMI
> matching:
>
> brcmfmac4330-sdio.Prowise-PT301.txt
> brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt
> brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt
>
> The others are either part of the DMI override table for devices with unsuitable
> DMI strings like "Default String"; or are device-tree based.
>
> So as long as we don't break those 3 (or break the ONDA one but get a symlink
> in place) we can sanitize a bit more then just non-printable and '/'.
>
> Kalle, Arend, what is your opinion on this?
>
> Note I do not expect the ONDA V80 Plus to have a lot of Linux users,
> but it definitely has some.

To me having spaces in filenames is a bad idea, but on the other hand we
do have the "don't break existing setups" rule, so it's not so simple. I
vote for not allowing spaces, I think that's the best for the long run,
but don't know what Arend thinks.

Maybe we could do some kind of fallback mechanism, like first trying the
sanitised filename and if that's not found then we try the old filename
with spaces? And if that old filename works we print a big fat warning
that the user should update the file and that the old "filename with
spaces" support is going away soon?

-- 
Kalle Valo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ