Hi Daniela
I am not convinced by the argument either but it was the response. A core piece of code like glexec should be well developed to avoid odd behaviour and resist error conditions that could potentially be exploited.
On the positive side the tickets being opened reporting problems are being tackled quickly by the developers - how quickly the fixes get into a production release was not clear.
Jeremy
On 7 Apr 2011, at 10:21, Daniela Bauer wrote:
> If you implement a feature/bug somebody is going to use it/exploit it/fall for it, whether on purpose or accidentally.
> I can't believe "we are relying on the users to deal with this" still counts as an argument in this day and age.
>
> Cheers,
>
> Daniela
>
>
> On 6 April 2011 20:08, Jeremy Coles <[log in to unmask]> wrote:
> Hi
>
> Stephen's point about argc was made more generally by Maarten in the GDB about other use cases. It seems the assumption was that site setups would only be used by jobs coming through the pilot job frameworks and that self-testing at sites will inevitably encounter other problems. Change of the directory being used by the job was another problem that "should" be avoided by developers of the pilot jobs. A twiki page is being put together by Maarten to better support the deployment of glexec.
>
> Jeremy
>
>
>
>
> On 6 Apr 2011, at 17:01, Stephen Burke wrote:
>
> > Testbed Support for GridPP member institutes [mailto:[log in to unmask]] On Behalf Of Daniela Bauer said:
> >> While he's got a point, the question why e.g. GGUS 69333 wasn't found by a security review remains.
> >
> > Probably the people who did the review also assumed that argc couldn't be 0! Also the review was looking for vulnerabilities, and it doesn't seem clear that a segfault is a vulnerability.
> >
> > Stephen
>
>
>
> --
> -----------------------------------------------------------
> [log in to unmask]
> HEP Group/Physics Dep
> Imperial College
> Tel: +44-(0)20-75947810
> http://www.hep.ph.ic.ac.uk/~dbauer/
|