.png files in /gnu/store with executable permissions (555)

  • Done
  • quality assurance status badge
Details
7 participants
  • Bengt Richter
  • Brett Gilio
  • Julien Lepiller
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • Ricardo Wurmus
  • zimoun
Owner
unassigned
Submitted by
Bengt Richter
Severity
normal

Debbugs page

B
B
Bengt Richter wrote on 28 Nov 2019 23:59
(name . New-Bug)(address . bug-guix@gnu.org)(name . Mark H Weaver)(address . mhw@netris.org)
20191129075938.GA55971@PhantoNv4ArchGx.localdomain
Hi Guix,

I was wanting to check on some executable files in the store,
and happened to see some executable .png files ;-/

I suspect they came in when I was playing with icecat
and let it load a "theme", but I am not sure some didn't
also happen trying to get firefox radio buttons to work ;-/

Anyway, does anyone else get 555 permissions on files like these?
These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.

Is this zero-day stuff with a nasty somewhere, waiting for referencing by another nasty, or am I being paranoid?
What is the safe way to detoxify this mess? I know I shouldn't directly chmod anything in store, right?

The icecat discussion got moved to mozilla, but in case someone else did whatever I did,
I thought I'd post a heads-up here.
I'll try to cc Mark :)

$ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
Toggle snippet (24 lines)
1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'


--
Regards,
Bengt Richter
R
R
Ricardo Wurmus wrote on 29 Nov 2019 01:49
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
87r21r9fn1.fsf@elephly.net
Bengt Richter <bokr@bokr.com> writes:

Toggle quote (26 lines)
> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
> --8<---------------cut here---------------start------------->8---
> 1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
> 1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
> 97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
> 1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
> 34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
> 1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
> 62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
> 1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
> 1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'
>
> --8<---------------cut here---------------end--------------->8---

Maybe I’m missing something, but none of the above are PNGs.
Most of them are executables, others are directories, so having them
executable is expected.

Did I misunderstand?

--
Ricardo
Z
Z
zimoun wrote on 29 Nov 2019 02:59
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ21-vxmBFrHp=26Cz7VMa+Z-e=i5o1wB8oGsE+96-M3pg@mail.gmail.com
Hi,

On Fri, 29 Nov 2019 at 11:43, Ricardo Wurmus <rekado@elephly.net> wrote:

Toggle quote (4 lines)
> Maybe I’m missing something, but none of the above are PNGs.
> Most of them are executables, others are directories, so having them
> executable is expected.

I am not sure to understand the issue but for example:

find /gnu/store/ -type f -perm /111 -iname '*.png' -print

returns this file:

/gnu/store/xj7kn8vw1nkcg7qpl3491b831p88i9wn-python-coverage-4.5.3/lib/python3.7/site-packages/coverage/htmlfiles/keybd_open.png


Hope that helps,
simon
T
T
Tobias Geerinckx-Rice wrote on 29 Nov 2019 03:28
87r21q9b1h.fsf@nckx
Bengt, Ricardo,

I see similar results here with ‘guix install moka-icon-theme’,
and I'm sure the rest of my (and everyone's) store is full of
misperm'd files too. It's kind of generally known.

This seems to be particularly common in Meson packages: for some
reason, Meson installs everything as executable by default.

Bengt Richter 写道：
Toggle quote (4 lines)
> Is this zero-day stuff with a nasty somewhere, waiting for
> referencing
> by another nasty, or am I being paranoid?

What's the threat model there? Respectfully, I think you might
be, but maybe I'm naive…

Otherwise I consider this a merely cosmetic issue, but we still
welcome fixes for those!

Checking whether Meson behaves differently on other distributions
would be a good start.

Ricardo Wurmus 写道：
Toggle quote (57 lines)
> Bengt Richter <bokr@bokr.com> writes:
>
>> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a
>> %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
>> --8<---------------cut
>> here---------------start------------->8---
>> 1 x
>> '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
>> 1 x
>> '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
>> 97 x
>> '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
>> 1 x
>> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
>> 1 x
>> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
>> 1 x
>> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
>> 1 x
>> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
>> 1 x
>> '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
>> 34143 x
>> '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
>> 1 x
>> '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
>> 62 x
>> '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
>> 1 x
>> '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
>> 1 x
>> '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
>> 1 x
>> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
>> 1 x
>> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
>> 1 x
>> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
>> 1 x
>> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
>> 1 x
>> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
>> 1 x
>> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
>> 1 x
>> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
>> 1 x
>> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'
>>
>> --8<---------------cut
>> here---------------end--------------->8---
>
> Maybe I’m missing something, but none of the above are PNGs.
> Most of them are executables, others are directories, so having
> them
> executable is expected.

Bengt's clever pipeline tallies the number of executable *png
files in each top-level store directory. It does not include
directories.

It's true that the '*png' above should be replaced with '*.png',
but these /bin files are just the very noisy outliers.

The meat is in:

Toggle quote (3 lines)
> 34143 x
> '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme

i.e. 34143 executable '*png' files in that directory alone.

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl3hANoACgkQ2Imw8BjF
STyoQw/8DY28FMGC7nexg4kH6CfHc7IQS3YoWG6EosQfagSQdKF0dZlWtQhuDLLH
l3e3yhXI03Aumu+mI/TkZcpNmUAWmkeuWUqlqb3ZRjQvbLUJaztRj23bb/ahVzQi
WGfHM9GejPLMDg70947V/SQPYcRo4MYf9lL5n2rEL2DvagSaTU6JfeOXbw3Xkchz
+AhyLvAPqt+8G8YIGSs7cyqYx/id+Gwal6rqs6zae0jD7dw/rIAOjqiDiCUPvGGD
U0saWXxkNi3YRpLsUExBj+RkCs8ZqATHq4/nB0a2aWbx4P3VjDlnZB+gAwLw4EB9
CidFl9QfiF6JzYtrYDuW7vN2mks/2hJjMNwrHXubeA8P4oMybOL20R43sGnBBy6J
WKi/S7toUAy2B4FV91d2GD2aqk62rScyMYN6tVFHmZaGA1s2hWAtrMns1xGz2ERq
XWsZd6DookQ9ezZlpw2M+WWLzKA4D8whZWE2WNIfVCEQw752liWScawQMJyJ3ahk
ZzOeNZs001esxdyoorYrZLRVHvAJ9SQrLXEnKNf7vQOR/WztKRM3UQlyyuQr4pFQ
agSRmHGwBKfKJ7+UzvOdRPXdkCzwI9TpS7sG6mtWgO2wF6AfUMfJhMnHmLw532U7
tQG9DltBQNx/CDt9zgp4JI9skaSTVlJs+S+hBiWVAebE6AqMvyw=
=aFZ0
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 29 Nov 2019 04:20
Re: .png files in /gnu/store with executable permissions (555)
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
878sny6fgr.fsf@netris.org
Hi Bengt,

Bengt Richter <bokr@bokr.com> wrote:
Toggle quote (7 lines)
> I was wanting to check on some executable files in the store,
> and happened to see some executable .png files ;-/
>
> I suspect they came in when I was playing with icecat
> and let it load a "theme", but I am not sure some didn't
> also happen trying to get firefox radio buttons to work ;-/

Certainly not. Unless you ran icecat as root, it would not have
sufficient permissions to modify /gnu/store. Installing a theme or
addon in IceCat, or changing its configuration, modifies files in your
~/.mozilla, not /gnu/store.

Toggle quote (4 lines)
> Anyway, does anyone else get 555 permissions on files like these?
> These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
> Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.

I looked at docbook-xsl-1.79.1, since I happen to have it installed on
my system. Some of the *.png files are incorrectly given executable
permissions within the upstream source tarball itself. I guess it's
probably the same issue with moka-icon-theme and faba-icon-theme, since
I don't see anything in our package code that would have done it.

Most of the entries in your list that end with "png" but not ".png" are
actually programs whose name ends with "png", so they *should* be
executable. The files in /gnu/store/.links that end with "png" are just
random chance, because the file names themselves are hashes.

Toggle quote (3 lines)
> Is this zero-day stuff with a nasty somewhere, waiting for referencing
> by another nasty, or am I being paranoid?

I think you're being paranoid in this case. I don't see anything here
to be concerned about, just some minor sloppiness by 3 upstreams.

Toggle quote (2 lines)
> What is the safe way to detoxify this mess?

The proper solution is to send bug reports to the upstream developers of
docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
the permissions of the *.png files in their source tarballs.

Toggle quote (2 lines)
> I know I shouldn't directly chmod anything in store, right?

Right, *never* modify files in /gnu/store directly.

Toggle quote (2 lines)
> The icecat discussion got moved to mozilla,

Which discussion are you referring to?

Thanks,
Mark
B
B
Bengt Richter wrote on 29 Nov 2019 04:22
Re: bug#38422: .png files in /gnu/store with executable permissions (555)
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 38422@debbugs.gnu.org)
20191129122236.GA67682@PhantoNv4ArchGx.localdomain
Attachment: file
B
B
Bengt Richter wrote on 29 Nov 2019 07:03
Re: .png files in /gnu/store with executable permissions (555)
(name . Mark H Weaver)(address . mhw@netris.org)(address . 38422@debbugs.gnu.org)
20191129150329.GA80736@PhantoNv4ArchGx.localdomain
Hi Mark.

On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
Toggle quote (15 lines)
> Hi Bengt,
>
> Bengt Richter <bokr@bokr.com> wrote:
> > I was wanting to check on some executable files in the store,
> > and happened to see some executable .png files ;-/
> >
> > I suspect they came in when I was playing with icecat
> > and let it load a "theme", but I am not sure some didn't
> > also happen trying to get firefox radio buttons to work ;-/
>
> Certainly not. Unless you ran icecat as root, it would not have
> sufficient permissions to modify /gnu/store. Installing a theme or
> addon in IceCat, or changing its configuration, modifies files in your
> ~/.mozilla, not /gnu/store.
>
Yes, d'oh ;-) I was writing the "PS." in my reply to Ricardo probably
while you were writing this :) There I extracted some
guix build -S tarball content and showed that that was the perm source.

Toggle quote (9 lines)
> > Anyway, does anyone else get 555 permissions on files like these?
> > These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
> > Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.
>
> I looked at docbook-xsl-1.79.1, since I happen to have it installed on
> my system. Some of the *.png files are incorrectly given executable
> permissions within the upstream source tarball itself. I guess it's
> probably the same issue with moka-icon-theme and faba-icon-theme, since
> I don't see anything in our package code that would have done it.
Yes, I found the bad perms in the tarball likewise.

Toggle quote (5 lines)
>
> Most of the entries in your list that end with "png" but not ".png" are
> actually programs whose name ends with "png", so they *should* be
> executable. The files in /gnu/store/.links that end with "png" are just
> random chance, because the file names themselves are hashes.
Yeah, I realized. Could have done a cleaner job, but I was also curious
how many legit executables ended in png.

Toggle quote (7 lines)
>
> > Is this zero-day stuff with a nasty somewhere, waiting for referencing
> > by another nasty, or am I being paranoid?
>
> I think you're being paranoid in this case. I don't see anything here
> to be concerned about, just some minor sloppiness by 3 upstreams.
>
IIRC I did read of jpeg images being used to obfuscate call-home info
in some tricky malware, so anomalies in the same kind of file triggered
the question of whether it could be accidentally on purpose ;-/

Toggle quote (6 lines)
> > What is the safe way to detoxify this mess?
>
> The proper solution is to send bug reports to the upstream developers of
> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
> the permissions of the *.png files in their source tarballs.
>
That I haven't done. Is there a standard way to do it?
"guix show moka-icon-theme" tells me homepage, but it would be nice
to have a guix show --verbose that would show bug reporting info :)

Toggle quote (9 lines)
> > I know I shouldn't directly chmod anything in store, right?
>
> Right, *never* modify files in /gnu/store directly.
>
> > The icecat discussion got moved to mozilla,
>
> Which discussion are you referring to?
>

Sorry, wrong zilla ;-p


Toggle quote (3 lines)
> Thanks,
> Mark

--
Regards,
Bengt Richter
M
M
Mark H Weaver wrote on 29 Nov 2019 20:08
Re: bug#38422: .png files in /gnu/store with executable permissions (555)
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
871rtq57kd.fsf@netris.org
Hi Bengt,

Bengt Richter <bokr@bokr.com> writes:

Toggle quote (7 lines)
> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
>> The proper solution is to send bug reports to the upstream developers of
>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
>> the permissions of the *.png files in their source tarballs.
>>
> That I haven't done. Is there a standard way to do it?

No.

Toggle quote (3 lines)
> "guix show moka-icon-theme" tells me homepage, but it would be nice
> to have a guix show --verbose that would show bug reporting info :)

It would be nice, but it would also be an enormous amount of work.
First we'd need to devise a way to represent that information, and then
we'd need to add it to each of our 10K+ packages. It would also be an
additional job to do when adding new packages. I'm not sure it's worth
all that work. We already record the home page, and from there it's
usually not much work to find how to report bugs. In cases where it
_is_ difficult to find out how to report bugs, that's arguably a problem
that should be fixed upstream.

What do you think?

Regards,
Mark
B
B
Brett Gilio wrote on 29 Nov 2019 20:24
(name . Mark H Weaver)(address . mhw@netris.org)
87sgm6t2i6.fsf@posteo.net
Mark H Weaver <mhw@netris.org> writes:

Toggle quote (12 lines)
> [...] In cases where it
> _is_ difficult to find out how to report bugs, that's arguably a problem
> that should be fixed upstream.
>
> What do you think?
>
> Regards,
> Mark
>
>
>

Agreed 100% with Mark.

--
Brett M. Gilio
J
J
Julien Lepiller wrote on 29 Nov 2019 23:45
(address . 38422@debbugs.gnu.org)
FCCE8805-6725-425D-99DE-4CCD2E00DCF4@lepiller.eu
Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
Toggle quote (33 lines)
>Hi Bengt,
>
>Bengt Richter <bokr@bokr.com> writes:
>
>> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
>>> The proper solution is to send bug reports to the upstream
>developers of
>>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to
>fix
>>> the permissions of the *.png files in their source tarballs.
>>>
>> That I haven't done. Is there a standard way to do it?
>
>No.
>
>> "guix show moka-icon-theme" tells me homepage, but it would be nice
>> to have a guix show --verbose that would show bug reporting info :)
>
>It would be nice, but it would also be an enormous amount of work.
>First we'd need to devise a way to represent that information, and then
>we'd need to add it to each of our 10K+ packages. It would also be an
>additional job to do when adding new packages. I'm not sure it's worth
>all that work. We already record the home page, and from there it's
>usually not much work to find how to report bugs. In cases where it
>_is_ difficult to find out how to report bugs, that's arguably a
>problem
>that should be fixed upstream.
>
>What do you think?
>
> Regards,
> Mark

Also, we should not encourage people to report bugs upstream directly. We have to evaluate whether the bug is on our side or theirs first to not drown them in useless bug reports :)
B
B
Bengt Richter wrote on 30 Nov 2019 12:07
(name . Julien Lepiller)(address . julien@lepiller.eu)
20191130200748.GA2661@PhantoNv4ArchGx.localdomain
On +2019-11-30 08:45:09 +0100, Julien Lepiller wrote:
Toggle quote (19 lines)
> Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
> >Hi Bengt,
> >
> >Bengt Richter <bokr@bokr.com> writes:
> >
> >> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> >>> The proper solution is to send bug reports to the upstream
> >developers of
> >>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to
> >fix
> >>> the permissions of the *.png files in their source tarballs.
> >>>
> >> That I haven't done. Is there a standard way to do it?
> >
> >No.
> >
> >> "guix show moka-icon-theme" tells me homepage, but it would be nice
> >> to have a guix show --verbose that would show bug reporting info :)
> >
┌───────────────────────────────────────────────────────────────────────┐
│ > >It would be nice, but it would also be an enormous amount of work. │
└───────────────────────────────────────────────────────────────────────┘
Toggle quote (9 lines)
> >First we'd need to devise a way to represent that information, and then
> >we'd need to add it to each of our 10K+ packages. It would also be an
> >additional job to do when adding new packages. I'm not sure it's worth
> >all that work. We already record the home page, and from there it's
> >usually not much work to find how to report bugs. In cases where it
> >_is_ difficult to find out how to report bugs, that's arguably a
> >problem
> >that should be fixed upstream.
> >
┌──────────────────────────┐
│ I think you are right :) │
├──────────────────────────┤
│ > >What do you think? │
│ > > │
│ > > Regards, │
│ > > Mark │
└──────────────────────────┘
Toggle quote (1 lines)
>
┌──────────────────────────────────────────────────────────────┐
│ I think you are also right -- I withdraw my suggestion :) │
├──────────────────────────────────────────────────────────────┤
│ > Also, we should not encourage people to report bugs │
│ upstream directly. We have to evaluate whether the bug is on │
│ our side or theirs first to not drown them in useless bug │
│ reports :) │
└──────────────────────────────────────────────────────────────┘
Hm, this seems like it could be important for good relations with upstream?
Should there be an official _distilled and filtered-for-upstream_
git bug repo that guix developers populate and upstream devs
(and anyone) can pull and grep the log of for their projects?
I could imagine (hallucinate ? :) some benfits:
1. First of all, we can all determine easily if there has been
an "official" report from guix to upstream, to avoid even bothering
guix developers.
2. If upstream devs know reports have been considered important enough
by guix developers to be put in the repo, they might pay more attention :)
There is a lot of tl;dr discussion in many bug-reporting logs, so upstream
would probably appreciate having curated reports.
3. The log would be a record. Commit hashes would become precise references.
4. To keep the main bug info stream clear of speculative chatty stuff
(though this sometimes contains critical clues, and belongs somewhere)
the repo could contain (per major upstream?) files for commentary or
miscellaneous that guix devs might want to pass on, but not clutter
the main report with. Of course urls into bugzilla etc can be useful
as concise see-further refs. All misc stuff optional.
4. The work flow for developers already exists for accepting things
into the guix package repo, so no major new patterns for everyone to learn.
5. Anyone interested could clone the repo and pull to it for "guix-official"
bug reporting status.
WDYT?
--
Regards,
Bengt Richter
Z
Z
zimoun wrote on 2 Dec 2019 07:20
(name . Bengt Richter)(address . bokr@bokr.com)
CAJ3okZ0ze6xgLKF8Ss6s4nxSn4Xh39KO7ooF7qO=juq6yakNQw@mail.gmail.com
On Sat, 30 Nov 2019 at 21:09, Bengt Richter <bokr@bokr.com> wrote:

Toggle quote (4 lines)
> Should there be an official _distilled and filtered-for-upstream_
> git bug repo that guix developers populate and upstream devs
> (and anyone) can pull and grep the log of for their projects?

The Guix bug database is public and can be browsed for example here
[1] or [2]. Yes, it is not friendly for upstream developer and one
needs some Guix knowledge to correctly find what one is looking for.
Debian has more friendly entry point: the package Tracker [3]. And the
webpage [4] should be improved to report our bug etc. (as Debian is
doing).

(Note that the Guix-HPC search interface is better but currently down.)




All the best,
simon
Z
Z
zimoun wrote on 21 Jan 2020 16:22
Bug status? '.png' files with executable permissions
CAJ3okZ2ZAs+Cf0k29Aafk-LUG4FTU=wtzEJmk8pqVJ==SQ7eNQ@mail.gmail.com
Dear Bengt,

The bug report [1] points out files with unexpected permission; based
on extension filename.



It is not an security issue or the Guix packager did not carefully
check the validity of these files.

If you are security paranoid, you *have to* check by yourself all the
files using "guix build -S" because in paranoid mode you cannot trust
Guix packagers (and Guix committers neither).


In normal mode, 2 options:

a- propose a patch to change the permission for each offending package
b- report upstream

Well, at least these 3 packages docbook-xsl, faba-icon-theme, and
moka-icon-theme comes with unexpected .png file permission.


On the long term, I am not convinced that adding automatic check and
permission change based on filename extension would really add Quality
Assurance. Because we are speaking about quality, not security.


I am inclined to close this bug. What do you think?

All the best,
simon
Z
Z
zimoun wrote on 21 Jan 2020 16:31
CAJ3okZ3fOHk-SHHq8xpKrDbNY-EfRLRKG5iPMORu60z5sQK1xw@mail.gmail.com
tags 38422 notabug
quit
B
B
Bengt Richter wrote on 21 Jan 2020 18:28
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 38422@debbugs.gnu.org)
20200122022830.GA22138@LionPure
Hi zimoun,

On +2020-01-22 01:22:45 +0100, zimoun wrote:
Toggle quote (35 lines)
> Dear Bengt,
>
> The bug report [1] points out files with unexpected permission; based
> on extension filename.
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422
>
>
> It is not an security issue or the Guix packager did not carefully
> check the validity of these files.
>
> If you are security paranoid, you *have to* check by yourself all the
> files using "guix build -S" because in paranoid mode you cannot trust
> Guix packagers (and Guix committers neither).
>
>
> In normal mode, 2 options:
>
> a- propose a patch to change the permission for each offending package
> b- report upstream
>
> Well, at least these 3 packages docbook-xsl, faba-icon-theme, and
> moka-icon-theme comes with unexpected .png file permission.
>
>
> On the long term, I am not convinced that adding automatic check and
> permission change based on filename extension would really add Quality
> Assurance. Because we are speaking about quality, not security.
>
>
> I am inclined to close this bug. What do you think?
>
> All the best,
> simon

Ok with me to close, thanks.

--
Regards,
Bengt Richter
Z
Z
zimoun wrote on 27 Jan 2020 11:55
(address . 38422-done@debbugs.gnu.org)
CAJ3okZ2WMr5Ha0wz9S=v2MY3oqCu9h+i3G2r8n77zCh_iyMxsg@mail.gmail.com
close 38422
stop
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 38422@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 38422
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch