ubuntu-bugcontrol team mailing list archive

[C de-Avillez <hggdh2@xxxxxxxxxx>]

On Thu, 3 May 2012 16:15:44 -0700
Brian Murray <brian@xxxxxxxxxx> wrote:

> On Tue, May 01, 2012 at 09:25:04PM +0100, TJ wrote:
> > Due to other commitments I allowed my membership (2006-2010) of the
> > bugcontrol team to lapse some time ago. I'm now in a position to
> > devote time to bug-control once more and am therefore requesting
> > membership.
> > 
> > 1. I'm always polite and cannot recall ever having a bad experience
> > with a bug reporter. I signed the code of conduct in 2006.
> > 
> > 2. I have read and understand the documentation and have applied it
> > extensively to bugs over a long period of time. I've re-read it now
> > to ensure I'm up to date.
> > 
> > 3. Sensitive data such as passwords or personally identifying
> > information (name, account numbers, digital certificate keys) can
> > sometimes be found in stack-traces as data in function arguments or
> > in the binary data of core dumps.
> > 
> > 4. I tend to roam the packages tackling bugs that lack love or
> > appear to be particularly challenging to analyse and trace.
> > Sometimes they come to my attention due to affecting me; other
> > times I might read about them in forums or mailing-lists or see
> > them mentioned on IRC.
> > 
> > 5. Bugs I've worked on. As well as triaging I generally go after the
> > cause of the bug and document my research (for others to follow on)
> > even if I can't provide a final bug-fix or work-around. Where I can
> > provide a fix I'll publish a patch and debdiff or link a code branch
> > and request an SRU where appropriate.
> > 
> > 5.1. HIGH. [Precise] sudo. Abort in libpam-mount due to
> > pam_open_session() not being called.
> > 
> > Analysis and tracing revealed this as a high importance bug because
> > it shows that sudo was not calling pam_open_session() when a valid
> > cached timestamp was present. This could theoretically expose new
> > vectors for privilege escalation.
> > 
> > https://launchpad.net/bugs/927828
> > 
> > 5.2 NORMAL/HIGH. [Lucid] ubuntuone-client. Ubuntuone-client software
> > wont start.
> > 
> > This was an 'annoyance' bug but also very visible to affected users
> > since it prevented access to ubuntu-one. I delved into the Python
> > code and identified a coding problem, published a corrective
> > workaround, and alerted the Ubuntu One team.
> > 
> > https://launchpad.net/bugs/666608
> > 
> > 5.3 HIGH. [Oneiric, Precise] mountall. could not mount
> > /dev/mapper/cryptswap1
> > 
> > This was a high importance bug that prevented encrypted swap being
> > mounted during boot. I was able to figure out a method of tracing
> > the early start-up to aid running and monitoring the processes
> > manually. That led to revealing one underlying cause (there were
> > two). I was able to develop a fix which was polished by Steve
> > Langasek. It also caused me to write analysis scripts to determine
> > the most efficient patch. It turned out the bug report covered 2
> > distinctly different problems which masked each other.
> > 
> > https:/launchpad.net/bugs/874774
> > 
> > 5.4 HIGH. [Oneiric] casper, upstart. PXE/NFS boot requires "IPAPPEND
> > 2" in PXE menus
> > 
> > For those affected this is of high or critical importance since it
> > caused a failure to boot of PXE clients. This affected my network
> > so I was the original reporter too. A simple report detailing a
> > package which broke existing functionality after upgrade without
> > any warning. This would mainly affect network and systems
> > administrators.
> > 
> > https://launchpad.net/bugs/923219
> > 
> > 5.5 HIGH. [Feisty onwards] apache2 2.1.5+. TCP_DEFER_ACCEPT causes
> > random HTTP connection failures in load-balanced web-server farms
> > 
> > In a web server-farm scenario that is fronted by hardware
> > load-balancers, in this case Juniper Redline aka DX, where the
> > load-balancers are configured to use TCP multiplexing (holding open
> > and re-using HTTP connections to the web servers) there exists the
> > potential for random, unexplained and untraceable connection
> > failures.
> > 
> > This bug was high priority for the e-commerce retailer since it
> > affected payment transactions amongst other things. I spent over a
> > week working on it, writing custom C tools and custom kernels,
> > until I was able to finally identify the cause (weakly written
> > standards and poor implementation) and suggest a fix (a one line
> > Apache config change).
> > 
> > https://launchpad.net/bugs/134274
> 
> While these bugs aren't the typical sort of triage that we see your
> research into the bugs is phenomenal.  Additionally, I recall your
> previous work and would be happy to have you back in the team.
> 
> Barring any objections I'll add you next week. 

+1

..C..

Attachment: signature.asc
Description: PGP signature