Processing control commands:
> tags -1 -moreinfo
Bug #827160 [release.debian.org] jessie-pu: package dosfstools/3.0.27-1+deb8u1
Removed tag(s) moreinfo.
--
827160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 -moreinfo
I believe I have provided all the requested information, and is
unsure how much of my proposed changes is accepted by the release
managers. Can someone let me know what the status of this proposal is?
--
Happy hacking
Petter Reinholdtsen
On Tue, Jul 5, 2016 at 10:37:41 +0200, Petter Reinholdtsen wrote:
> [Andreas Bombe]
> > If you strongly expect it to be accepted as it is, then push it.
> >
> > Or wait with tagging until it is accepted. Moving tags and releases
> > that aren't releases after all is something I'd like to avoid.
>
[Adam D. Barratt]
> I intentionally asked for a debdiff, not a pointer to a repository. Bug
> reports should stand alone and not be reliant on external resources
> which may change or disappear.
>
> Is the diff in <2fla8ikrwpn@diskless.uio.no> still current?
I did not provide a debdiff, becaus
On Thu, 2016-07-07 at 21:45 +0200, Petter Reinholdtsen wrote:
> [Adam D. Barratt]
> > The version in unstable has:
> >
> > if (month < 0) {
> > /* make sure that nothing bad happens if the month bits were zero */
> > month = 0;
> > }
> >
> > which seems like a more minimal-s
[Adam D. Barratt]
> The version in unstable has:
>
> if (month < 0) {
> /* make sure that nothing bad happens if the month bits were zero */
> month = 0;
> }
>
> which seems like a more minimal-style change than the assert. Could we
> have an updated debdiff including that c
On Sat, 2016-06-18 at 09:21 +0200, Petter Reinholdtsen wrote:
> [Andreas Bombe]
> diff --git a/src/check.c b/src/check.c
> index e8aaf92..086b923 100644
> --- a/src/check.c
> +++ b/src/check.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include "common.h"
> #inc
[Andreas Bombe]
> If you strongly expect it to be accepted as it is, then push it.
>
> Or wait with tagging until it is accepted. Moving tags and releases
> that aren't releases after all is something I'd like to avoid.
Right. I believe the changes are sound and suspect the release team
agree wit
On Sun, Jun 26, 2016 at 09:27:57AM +0200, Petter Reinholdtsen wrote:
>
> Andreas, while I wait for a reply from the release managers, it would be
> great to know the answer to this question:
>
> [Petter Reinholdtsen]
> > OK to push it to the collab-maint git repo before upload, or should I
> > wa
Andreas, while I wait for a reply from the release managers, it would be
great to know the answer to this question:
[Petter Reinholdtsen]
> OK to push it to the collab-maint git repo before upload, or should I
> wait until it is accepted?
--
Happy hacking
Petter Reinholdtsen
On Sat, Jun 18, 2016 at 09:21:58AM +0200, Petter Reinholdtsen wrote:
> [Andreas Bombe]
> > Also, I wonder if the fix for
> > https://github.com/dosfstools/dosfstools/issues/11 (which is
> > 2aad1c83c) shouldn't also be included while we're at it. It has no
> > CVE, the out of bounds memory access i
[Andreas Bombe]
> I didn't look closely when the wheezy update was uploaded, so it looks
> like it missed it.
>
> For reference, this is the original report including a test file:
> https://github.com/dosfstools/dosfstools/issues/12
>
> The problem is fixed if fsck'ing that file under valgrind show
On Fri, Jun 17, 2016 at 06:37:03AM +0100, Adam D. Barratt wrote:
> On Fri, 2016-06-17 at 05:00 +0200, Andreas Bombe wrote:
> > On Mon, Jun 13, 2016 at 09:26:52AM +0200, Petter Reinholdtsen wrote:
> [...]
> > > https://security-tracker.debian.org/tracker/CVE-2016-4804 >
> > > https://security-tracke
[Petter Reinholdtsen]
> I will. But the comment below seem to indicate that the update in
> Wheezy was incomplete?
Looking at the code, I am quite sure the Wheezy fix missed the change in
https://github.com/dosfstools/dosfstools/commit/07908124838afcc99c577d1d3e84cef2dbd39cb7
>.
Who should be no
[Andreas Bombe]
> Yes, please go ahead after taking into account the remark below. Thank
> you.
I will. But the comment below seem to indicate that the update in
Wheezy was incomplete?
> This is commit 39ce90fe7 [*] which fixed a possible read access one
> byte beyond the end of an array, pretty
On Fri, 2016-06-17 at 05:00 +0200, Andreas Bombe wrote:
> On Mon, Jun 13, 2016 at 09:26:52AM +0200, Petter Reinholdtsen wrote:
[...]
> > https://security-tracker.debian.org/tracker/CVE-2016-4804 >
> > https://security-tracker.debian.org/tracker/CVE-2016-4804 >.
> >
> > The issues were fixed in Whe
On Mon, Jun 13, 2016 at 09:26:52AM +0200, Petter Reinholdtsen wrote:
>
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-CC: Andreas Bombe
>
> On my Debian Jessie machine, I would like to fix the two security
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Andreas Bombe
On my Debian Jessie machine, I would like to fix the two security issues
in dosfstools that show up in the debsecan report:
https://security-tracker.deb
18 matches
Mail list logo