From roger.lipp at hp.com Mon Oct 1 04:46:58 2012 From: roger.lipp at hp.com (Lipp, Roger D (Mission Critical Linux)) Date: Mon, 1 Oct 2012 04:46:58 +0000 Subject: Self-Introduction: Roger Lipp and a ruby command-line tool for bugzilla Message-ID: Let me introduce myself. My name is Roger Lipp. I'm in sunny San Jose, California working for Hewlett-Packard. I'm interested in helping out with the WebServices API for bugzilla. I've been working in Perl for longer than I'd really care to admit. I also do webservices with RoR and django. I have been struggling to get a command-line tool to interface to bugzilla webservices through a corporate firewall. I love the "bugzilla" cli tool that is part of the bugzilla package (I believe this was provided in order to demonstrate the webservices interface). But I was not able to get it to work through our firewall. After searching through Google for a while, I decided to write a simple tool that was based on a firewall-friendly xmlrpc library. For this I chose to use "ruby". I kept the script simple enough to easily expose the method of using WebServices, while functional enough to be useful. I would love to contribute my work to bugzilla, perhaps as a "ruby example of using the webservices api", or as a command-line interface that works behind a corporate firewall. Is this of interest? Thank you, Roger Lipp roger.lipp at hp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven_tierney at yahoo.co.uk Tue Oct 2 18:42:13 2012 From: steven_tierney at yahoo.co.uk (Steven Tierney) Date: Tue, 2 Oct 2012 19:42:13 +0100 (BST) Subject: Customisable Custom Field Autocomplete Message-ID: <1349203333.13762.YahooMailNeo@web29703.mail.ird.yahoo.com> Hi, Just to announce a feature I have developed: ?A customisable autocompletion feature for Bugzilla Custom Fields. The source is available at?https://sourceforge.net/projects/cfautocomplete/ I'm no Perl or Bugzilla guru but it has worked for me in the light testing I have done. ?Feel free to give it a whirl! Regards,? --- Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue Oct 2 18:47:13 2012 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 02 Oct 2012 20:47:13 +0200 Subject: Self-Introduction: Roger Lipp and a ruby command-line tool for bugzilla In-Reply-To: References: Message-ID: <506B36B1.4030203@gmail.com> Le 01. 10. 12 06:46, Lipp, Roger D (Mission Critical Linux) a ?crit : > I would love to contribute my work to bugzilla, perhaps as a "ruby > example of using the webservices api", or as a command-line interface > that works behind a corporate firewall. > > Is this of interest? Hello Roger, All contributions are always welcome, but why choosing Ruby rather than Perl as the whole Bugzilla application is written in Perl? :) Is your CLI running on the server-side or client-side? This part is a bit unclear to me. LpSolit From roger.lipp at hp.com Tue Oct 2 20:49:43 2012 From: roger.lipp at hp.com (Lipp, Roger D (Mission Critical Linux)) Date: Tue, 2 Oct 2012 20:49:43 +0000 Subject: Self-Introduction: Roger Lipp and a ruby command-line tool for bugzilla In-Reply-To: <506B36B1.4030203@gmail.com> References: <506B36B1.4030203@gmail.com> Message-ID: > -----Original Message----- > From: Fr?d?ric Buclin [mailto:lpsolit at gmail.com] > Sent: Tuesday, October 02, 2012 11:47 AM > To: developers at bugzilla.org > Cc: Lipp, Roger D (Mission Critical Linux) > Subject: Re: Self-Introduction: Roger Lipp and a ruby command-line tool for bugzilla > > Le 01. 10. 12 06:46, Lipp, Roger D (Mission Critical Linux) a ?crit : > > I would love to contribute my work to bugzilla, perhaps as a "ruby > > example of using the webservices api", or as a command-line interface > > that works behind a corporate firewall. > > > > Is this of interest? > > > Hello Roger, > > All contributions are always welcome, but why choosing Ruby rather than > Perl as the whole Bugzilla application is written in Perl? :) > > Is your CLI running on the server-side or client-side? This part is a > bit unclear to me. > > > LpSolit Hello Fr?d?ric, This script runs on the client side. Ruby was a nice choice because of the ability to easily deal with different encodings (XML, YAML, JSON). By using ruby I don't have a lot of clutter in the code to handle these issues. To give you a better idea of what I'm doing, here is the help output from my script: $ rbugz --help Usage: rbugz [options] [bugid] General Options: -h, --help Display this screen -v, --verbose Output more information --version Display version information. rbugz 0.2 --server=SERVER Select which bugzilla server to interact with. Defaults defined in /opt/rbugz/etc/servers.yaml -x, --xml display results in XML format (default is YAML) -j, --json display results in JSON format (default is YAML) -i, --include=FIELDLIST a comma-separated list of fields to include in the output Login Options: -l, --login login to bugzilla. Your login cookie will be stored in ~/.bugzilla-cookies. -u, --user=USER bugzilla user name -p, --password=PASSWORD bugzilla password. Omit this option to be prompted for your password Defect Lookup Options: -a, --all display all available information about the bug -t, --attachments display only attachments associated with bug -c, --comments display only comments associated with bug -s, --history display history of changes for the bug Query Options: -q, --query=FILENAME specify a YAML file that contains the query paramenter. STDIN may be passed as the filename The fun stuff is in the query option. It turns out that the combination of YAML and xmlrpc is a pretty natural fit. The query file can contain things like: creator: roger.lipp at hp.com status: [ASSIGNED, OPEN] Ruby's yaml library will read that in and generate a hash, which can then be handed directly to the xmlrpc call. All in all, I think this provides a good working example of how to use the WebServices API on the client side. -Roger From anna.pakkala at nokia.com Mon Oct 15 10:20:20 2012 From: anna.pakkala at nokia.com (anna.pakkala at nokia.com) Date: Mon, 15 Oct 2012 10:20:20 +0000 Subject: Self-Introduction: Anna Pakkala Message-ID: <4E3D74162D6A0949BE2650033FF2D80B480AF950@008-AM1MPN1-024.mgdnok.nokia.com> Hello everyone! Name: Anna Pakkala irc nick: rocknroll country: Finland Job title: Specialist, Fault Management Company: Nokia I?d like to contribute to loads of things, but mainly would like to introduce usability enhancements, as those are the things we have been furiously working on at Nokia. Historical qualifications: * I have 10+ years of software development experience in several languages, lately mainly perl. I am a web developer through and through, with skills in css, html, html5, javascript & ajax as well as server side scripting languages and databases (and some other stuff) ? * I have worked on Bugzilla exclusively for about a year, with most of our development activities focused on extensions, NOT the core Bugzilla. Current version of our bz is 4.02. At Nokia we use 4 different, heavily customized Bugzilla instances with about a thousand users in all. We have quite specific needs for our fault management, so during this past year we have introduced some great new functionality that I think would benefit the whole Bugzilla community. We have lots of ideas! So, I now have an officially sanctioned, Bugzilla community allotted slice of my time that I can (and should) use for the benefit of Bugzilla :) -- Anna Pakkala Specialist, Fault Management SD Nokia Lumia Quality/SWES http://www.linkedin.com/pub/anna-pakkala/5/495/539 From justdave at bugzilla.org Tue Oct 16 04:33:31 2012 From: justdave at bugzilla.org (Dave Miller) Date: Tue, 16 Oct 2012 00:33:31 -0400 Subject: Self-Introduction: Anna Pakkala In-Reply-To: <4E3D74162D6A0949BE2650033FF2D80B480AF950@008-AM1MPN1-024.mgdnok.nokia.com> References: <4E3D74162D6A0949BE2650033FF2D80B480AF950@008-AM1MPN1-024.mgdnok.nokia.com> Message-ID: <507CE39B.1080506@bugzilla.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 anna.pakkala at nokia.com wrote on 10/15/12 6:20 AM: > Hello everyone! Welcome! > So, I now have an officially sanctioned, Bugzilla community > allotted slice of my time that I can (and should) use for the > benefit of Bugzilla :) Yay! - -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQfOOb0YeDAOcbS44RAn2LAJ9mhtDup4ODyTkdjJ++GYNhp9ZP9QCfS4cV GXb6T38+V2FmIyUKJl268n8= =zkSq -----END PGP SIGNATURE----- From justdave at bugzilla.org Tue Oct 16 04:35:49 2012 From: justdave at bugzilla.org (Dave Miller) Date: Tue, 16 Oct 2012 00:35:49 -0400 Subject: Customisable Custom Field Autocomplete In-Reply-To: <1349203333.13762.YahooMailNeo@web29703.mail.ird.yahoo.com> References: <1349203333.13762.YahooMailNeo@web29703.mail.ird.yahoo.com> Message-ID: <507CE425.8090201@bugzilla.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Tierney wrote on 10/2/12 2:42 PM: > Hi, > > Just to announce a feature I have developed: A customisable > autocompletion feature for Bugzilla Custom Fields. > > The source is available at > https://sourceforge.net/projects/cfautocomplete/ > > I'm no Perl or Bugzilla guru but it has worked for me in the light > testing I have done. Feel free to give it a whirl! Cool! You should add this to https://wiki.mozilla.org/Bugzilla:Addons - -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQfOQl0YeDAOcbS44RAmV+AJ9Q/WZ44gVzkk16qX76JiLq3YrDPwCeJDGx GiJD53qKp5LDPz4KoplHZgU= =dZny -----END PGP SIGNATURE----- From jochen.wiedmann at gmail.com Tue Oct 16 09:23:53 2012 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 16 Oct 2012 11:23:53 +0200 Subject: Customisable Custom Field Autocomplete In-Reply-To: <507CE425.8090201@bugzilla.org> References: <1349203333.13762.YahooMailNeo@web29703.mail.ird.yahoo.com> <507CE425.8090201@bugzilla.org> Message-ID: Or, much better, contribute it to the core by opening a bug with the necessary patch. On Tue, Oct 16, 2012 at 6:35 AM, Dave Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Steven Tierney wrote on 10/2/12 2:42 PM: >> Hi, >> >> Just to announce a feature I have developed: A customisable >> autocompletion feature for Bugzilla Custom Fields. >> >> The source is available at >> https://sourceforge.net/projects/cfautocomplete/ >> >> I'm no Perl or Bugzilla guru but it has worked for me in the light >> testing I have done. Feel free to give it a whirl! > > Cool! You should add this to https://wiki.mozilla.org/Bugzilla:Addons > > - -- > Dave Miller http://www.justdave.net/ > IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iD8DBQFQfOQl0YeDAOcbS44RAmV+AJ9Q/WZ44gVzkk16qX76JiLq3YrDPwCeJDGx > GiJD53qKp5LDPz4KoplHZgU= > =dZny > -----END PGP SIGNATURE----- > - > To view or change your list settings, click here: > -- The best argument for celibacy is that the clergy will sooner or later become extinct. From justdave at bugzilla.org Thu Oct 18 19:29:34 2012 From: justdave at bugzilla.org (Dave Miller) Date: Thu, 18 Oct 2012 15:29:34 -0400 Subject: Bugzilla's documentation In-Reply-To: <4FEAFBAB.20309@mozilla.org> References: <4FEAFBAB.20309@mozilla.org> Message-ID: <5080589E.8040004@bugzilla.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gervase Markham wrote on 6/27/12 8:25 AM: > On 25/06/12 12:50, Byron Jones wrote: >> what's wrong with having different namespaces: >> http://wiki.bugzilla.org/docs/4.0/en/html/ >> http://wiki.bugzilla.org/docs/4.2/en/html/ > > One problem with this is that, AFAIK, MediaWiki has no "Copy Tree" > function which would allow us to say: > > "Take everything under http://wiki.bugzilla.org/docs/trunk and copy > it to http://wiki.bugzilla.org/docs/4.4". > > If there is such an extension, point me at it :-) > > The second is that it's much harder to apply a patch to multiple > branches on a wiki which is only editable over the web. I'm reviving a really old thread here, but it appears we never came to a final conclusion on it yet... developer.mozilla.org recently changed their backend software. The new software is very wiki-like for editing documentation pages. You can request an edit be reviewed by someone else before it goes live (optionally right now - probably wouldn't take much to make it force that). On the roadmap is per-product skins and context-sensitive page display (set a dropdown for what version/OS/whatever you're running it on and the docs update to match, so we could do version-specific documentation and make the new stuff only show up on the page for the newer versions, etc). Mozilla has developers being paid to add those features since they need them for Marketplace/Addons.mozilla.org integration. It'll probably be 3 to 6 months before the software gets up to that point but with those features in place it strikes me that it might be a really good match for our needs to get a CMS backing our docs instead of using Docbook. - -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQgFie0YeDAOcbS44RAjOjAJwM9Nu4Xeg+ioLeNjqDrw+ShHoz7ACfaKCY /IFFhg65GWfaLWDqj7ZFVys= =IK7h -----END PGP SIGNATURE----- From gerv at mozilla.org Wed Oct 24 13:48:39 2012 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 24 Oct 2012 14:48:39 +0100 Subject: Secure-by-default APIs Message-ID: <5O2dnQAQypsrbBrNnZ2dnUVZ_rudnZ2d@mozilla.org> A confidential information leak bug (bug 803992, still hidden) has recently been reported against a template shipped with BzAPI. There have been other similar bugs recently. These bugs have the common factor that a template called an API to get some data, and was given data that the currently logged-in user was not supposed to see. The template was, apparently, responsible for implementing whatever checks are necessary to filter the data, but did not do so. I would like to suggest that this is an anti-pattern. We should instead be creating APIs which are "secure by default", i.e. they return only data the currently-logged-in user is permitted to see. If an API for returning all the data is necessary, we should have a separate one, with a known marking so uses of those APIs in the codebase can be audited. I will suggest, as a straw man, the pattern that e.g. "object.things" be the secure version, and "object.all_things" be the insecure version. It will not be obvious or simple to transition fully to this kind of model, and we would need to do so in stages and as time permits. But it seems to me that sticking with the current system is going to lead to people - both Bugzilla devs and those making custom templates for their own systems - to create information leak bugs again and again. People cannot be expected to know that when you call object.things, you then need to manually remove all things which are in group 23 (or whatever) before displaying the list to the user. Comments? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From sdaugherty at gmail.com Wed Oct 24 15:41:59 2012 From: sdaugherty at gmail.com (Stephanie Daugherty) Date: Wed, 24 Oct 2012 11:41:59 -0400 Subject: Secure-by-default APIs In-Reply-To: <5O2dnQAQypsrbBrNnZ2dnUVZ_rudnZ2d@mozilla.org> References: <5O2dnQAQypsrbBrNnZ2dnUVZ_rudnZ2d@mozilla.org> Message-ID: On Wed, Oct 24, 2012 at 9:48 AM, Gervase Markham wrote: > A confidential information leak bug (bug 803992, still hidden) has > recently been reported against a template shipped with BzAPI. There have > been other similar bugs recently. These bugs have the common factor that a > template called an API to get some data, and was given data that the > currently logged-in user was not supposed to see. The template was, > apparently, responsible for implementing whatever checks are necessary to > filter the data, but did not do so. > > I would like to suggest that this is an anti-pattern. We should instead be > creating APIs which are "secure by default", i.e. they return only data the > currently-logged-in user is permitted to see. If an API for returning all > the data is necessary, we should have a separate one, with a known marking > so uses of those APIs in the codebase can be audited. I will suggest, as a > straw man, the pattern that e.g. "object.things" be the secure version, and > "object.all_things" be the insecure version. > > It will not be obvious or simple to transition fully to this kind of > model, and we would need to do so in stages and as time permits. But it > seems to me that sticking with the current system is going to lead to > people - both Bugzilla devs and those making custom templates for their own > systems - to create information leak bugs again and again. People cannot be > expected to know that when you call object.things, you then need to > manually remove all things which are in group 23 (or whatever) before > displaying the list to the user. > > Comments? > > This sounds like very much the right approach. I suggest that as a interim first step, rename the functions that can return unsantitized data with some sort of prefix, so that it's easy to audit code to find where information leaks may be happening by looking for a particular string. ie, hypothetically, get_all_bugs() might become unsantitized_get_all_bugs(), and get_all_bugs() would be replaced by a stub that logs a debug message so as not to break existing code. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Thu Oct 25 12:45:44 2012 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 25 Oct 2012 14:45:44 +0200 Subject: Secure-by-default APIs In-Reply-To: References: <5O2dnQAQypsrbBrNnZ2dnUVZ_rudnZ2d@mozilla.org> Message-ID: <50893478.9070604@gmail.com> Le 24. 10. 12 17:41, Stephanie Daugherty a ?crit : >> I would like to suggest that this is an anti-pattern. We should instead be >> creating APIs which are "secure by default", i.e. they return only data the >> currently-logged-in user is permitted to see. This is what we do already! The Bugzilla API is the WebServices interface, not internal methods used by Bugzilla itself. This internal part is not an API. Our API (WebServices) is secure by default. If you read the documentation related to the bug you are talking about correctly, it says "Returns *all* products of the classification." This is very clear and unambiguous. I will veto the kind of changes you have in mind. We already have very explicit methods like $user->get_accessible_products to return exactly what you are asking for. If some methods need more detailed documentation, then fix the documentation. Renaming methods used for ages is just going to break existing extensions and confuse developers used to them. >> straw man, the pattern that e.g. "object.things" be the secure version, and >> "object.all_things" be the insecure version. I don't want all_foo() methods appearing when our documentation is explicit enough. Moreover, your naming isn't better at all. When sending data by email (bugmails, flagmails, whinemails), the credentials of the logged in user is irrelevant. What matters are credentials of the one getting the email. We are not going to add a 3rd method object.things_for_user_going_to_get_the_email. >> seems to me that sticking with the current system is going to lead to >> people - both Bugzilla devs and those making custom templates for their own >> systems - to create information leak bugs again and again. People cannot be >> expected to know that when you call object.things, you then need to >> manually remove all things which are in group 23 (or whatever) before >> displaying the list to the user. I disagree. They are supposed to know. Methods are documented. If you want a safe interface, use our WebServices interface. But even in this case, your statement may fail if one user is getting data for another user with different credentials. >> Comments? I think I have been very explicit above. :) >> This sounds like very much the right approach. I disagree totally! > ie, hypothetically, get_all_bugs() might become > unsantitized_get_all_bugs(), and get_all_bugs() would be replaced by a stub > that logs a debug message so as not to break existing code. This doesn't make sense. get_all_bugs() means get *ALL* bugs. LpSolit From nicolasbize at gmail.com Fri Oct 26 11:45:54 2012 From: nicolasbize at gmail.com (Nicolas Bize) Date: Fri, 26 Oct 2012 13:45:54 +0200 Subject: Self-Introduction: Nicolas Bize Message-ID: Hi everyone, My name is Nicolas Bize (usually called Nico). I live in Toulouse, Southern France. I currently work as a remote engineer for Qualys. I currently work mainly on a product called WAS (Web Application Scanning) that runs on a j2ee / extJs platform. I have good experience with the .Net world, sold my own software to one of the biggest insurance company in Europe. I have worked mostly on web apps for the past 5 years, mostly java and php based. I do some RoR on my free time. I graduated from a french engineering school in networks / telecommunications and ended up doing extensive C / C++ for Airbus after that. On a personal side, I am married with two boys ages 1 & 3. I love tennis and programming. My first computer was a 286 / 20Mhz on which I hosted / tweaked a BBS in San Francisco a couple years back. (Don't ask me to provide ANSI art though :) Anyways, we use Bugzilla at work and I'd be happy to free a bit of time to help out with bugs / features! Cheers, Nico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladd at bugzilla.org Fri Oct 26 23:47:18 2012 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sat, 27 Oct 2012 02:47:18 +0300 Subject: Secure-by-default APIs In-Reply-To: <50893478.9070604@gmail.com> References: <5O2dnQAQypsrbBrNnZ2dnUVZ_rudnZ2d@mozilla.org> <50893478.9070604@gmail.com> Message-ID: > If some methods need more detailed documentation, then fix the documentation. > [...] > I disagree. They are supposed to know. Gerv wasn't talking about fixing docs or what people are supposed to know (or do). He was proposing a solution for fixing a development *process* (as a result of doing research on previous security incidents related to Bugzilla). > I will veto the kind of changes you have in mind It's too early to veto things when the discussion didn't even happen yet. Gerv's proposals have obviously room for improvement, such as your suggestion about the case when the user which receives the mail is relevant for permission-checking. But his fundamentals are sound - we have a pattern in security flaws due to bad template filtering, and just like we audit the FILTER directives, we should brainstorm on fixing this as well. > Renaming methods used for > ages is just going to break existing extensions and confuse developers > used to them. Maybe an annotation in a comment right above the function definition, that could be checked by a simple static code analyzer tool? Examples: # Security: all (the function following this line returns all the information, unfiltered for security access) # Security: $user (1) (the function following this line returns the information visible for user $user given as parameter 1 to the function) Best regards, Vlad