> while the coverage is still tiny, there is an effort to collect contact
> addresses listed in the debian/upstream file in the VCS where our source
> packages are maintained.
>
> http://upstream-metadata.debian.net/table/contact
>
> In some cases, it is a valid email address. Perhaps you can
> I do not think that you should try to implement this immediately but
> from a Debian Maintainers point of view we now could present a case
> where it makes perfectly sense to use DEP5 formated copyright files and
> if we try to do this more strictly future tests could profit from it.
For our pur
On Thu, Jun 27, 2013 at 9:25 AM, Andreas Tille wrote:
> The Debian Med team was flooded by about 50 mails which is hard to cope
> in two weeks.
You shouldn't have received that many emails. If we decide to report
more bugs in the future (depending on the reactions from the
community), we will mak
On Thu, Jun 27, 2013 at 5:11 AM, Aron Xu wrote:
> I wonder whether you have checked where the crash is caused, you have
> sent several mails to me for every binary in your test run, but in
> dmesg.txt you provided all of them are from the very same library.
> This will cause lots of duplicates, an
Hi
> I wished the respective report would have been sent to the upstream
> developers,
> not to Debian. We could have been a second resort when upstream does not
> react to the reports (not unlikely, admittedly). Now, the Debian maintainer
> sees the findings two weeks before the bug is made publ
> One such crash was reported on a small fluxbox tool to be manually run,
> which used $HOME blindly. When it ran, it segfaulted, which is a bug,
> yes.
>
> However, it's not security, and to see the bug tagged 'security' was
> troubling - what oversight do you have to prevent the security team to
On Thu, Jun 27, 2013 at 3:30 AM, Paul Wise wrote:
> BTW, the mails you have been sending with links to the crashes have
> been going to publicly archived lists, not sure if you meant for that
> to happen though?
I realize only now that many emails (about 20% in our case), that are
listed as pack
Hi,
> I understand. But two weeks might be a bit too short for the majority
> of those crashes. Many upstream authors don't get paid for working on
> their software.
I first want to clarify the purpose of the two-week delay to make sure
we are on the same page.We do not expect upstream developers
Hi,
On Tue, Jun 25, 2013 at 2:03 PM, Dmitrijs Ledkovs
wrote:
> From Ubuntu point of view, we'd also be interested in a similar
> analysis. Unlike Debian we provide automatically generated packages
> with debug symbols.
> Similar to debian, we would most interested for development series to
> be t
Hi,
On Tue, Jun 25, 2013 at 11:38 AM, Marc Haber
wrote:
> Will you also check Debian unstable? It is much easier to have a
> package in unstable fixed, and I suspect that not every crash you find
> will be a security relevant one.
We actually already did :) We re-ran all the crashes on debian
un
ier 'OdyX' Raboud wrote:
> Hi
>
> Le mardi, 25 juin 2013 07.28:10, Alexandre Rebert a écrit :
>> I am a security researcher at Carnegie Mellon University, and my team
>> has found thousands of crashes in binaries downloaded from debian
>> wheeze packages. Af
Hi,
Thanks for all the feedback and comments. I tried to address all them below.
> The crash.sh script seems to set LD_LIBRARY_PATH. Is that actually
> needed? I'd prefer something that doesn't need something like that,
> since being able to crash apps if you load a broken library isn't very
>
Hi,
I am a security researcher at Carnegie Mellon University, and my team
has found thousands of crashes in binaries downloaded from debian
wheeze packages. After contacting ow...@bugs.debian.org, Don Armstrong
advised us to contact you before submitting ~1.2K bug reports to the
Debian BTS using m
13 matches
Mail list logo
