emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29182: closed (CVE-2017-1000383: umask and backup files)


From: GNU bug Tracking System
Subject: bug#29182: closed (CVE-2017-1000383: umask and backup files)
Date: Mon, 10 Aug 2020 16:26:02 +0000

Your message dated Mon, 10 Aug 2020 09:25:39 -0700
with message-id 
<CADwFkm=gFVrPN0bTGB9jp52gCwGEtEMGVPEcBpbD3_LnQKC2QQ@mail.gmail.com>
and subject line Re: bug#29182: CVE-2017-1000383: umask and backup files
has caused the debbugs.gnu.org bug report #29182,
regarding CVE-2017-1000383: umask and backup files
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
29182: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29182
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: CVE-2017-1000383: umask and backup files Date: Mon, 06 Nov 2017 16:56:18 -0500 User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
Package: emacs
Version: 25.3
Tags: security

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383

  GNU Emacs version 25.3.1 (and other versions most likely) ignores umask
  when creating a backup save file ("[ORIGINAL_FILENAME]~") resulting in
  files that may be world readable or otherwise accessible in ways not
  intended by the user running the emacs binary.

[I'm not sure why this apparently hasn't been reported here before now?]



--- End Message ---
--- Begin Message --- Subject: Re: bug#29182: CVE-2017-1000383: umask and backup files Date: Mon, 10 Aug 2020 09:25:39 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Stefan Kangas <stefan@marxist.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Glenn Morris <rgm@gnu.org>
>>> Date: Mon, 13 Nov 2017 17:04:55 -0500
>>>
>>> Rightly or wrong, distributions etc pay attention to CVEs, so I think
>>> an official response from Emacs on this issue would be good.
>>
>> I'm not sure how should we provide an official response there.  The
>> list there is mostly of issues with very old versions, and there's a
>> reference to bug reports which were closed.  What else is needed?  And
>> what's the procedure?
>
> OK, so this is almost 2 years old now, but I've looked into it a bit.

That was 44 weeks ago.

> This CVE has been rejected by at least Debian ("this CVE assignment is
> nonsense"), Redhat (bug has status "CLOSED WONTFIX") and Gentoo (bug has
> status "INVALID").
>
> I think it's fair to say that we don't want to "fix" this, since it
> should not really have been a CVE in the first place.
>
> I suggest to do the following:
>
> 1. There is a CVE status called disputed.  We should try to acquire that
>    status.  More information at:
>    https://cve.mitre.org/about/faqs.html#disputed_signify_in_cve_entry
>
>    It would be good if someone more senior than me tried to contact
>    MITRE, who handles the CVE to see how that works.  AFAICT, the way to
>    contact them is through this web form: https://cveform.mitre.org/
>
> 2. Tag this bug as wontfix.
>
> If MITRE don't reply, or do nothing -- fine, we close the bug.  If they
> do reply, or better yet add the status disputed -- good, it's there for
> posterity.  We then close the bug.

No one seemed interested in doing (1) and I've tagged the bug as
proposed in (2).

I'm therefore closing this bug report now.

Best regards,
Stefan Kangas


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]