From aliustek at gmail.com Tue Apr 3 19:13:24 2012 From: aliustek at gmail.com (rojanu) Date: Tue, 3 Apr 2012 12:13:24 -0700 (PDT) Subject: Bringing Testopia to up to Bugzilla 4.2 Message-ID: <6b4a8c89-e181-407d-9200-ed6b0b9f69f3@k14g2000vbe.googlegroups.com> Hi All, I have some spare time, for which I am planning to use to get Testopia up to Bugzilla 4.2. But don't want to duplicate somebody else's effort. I just run a search on bmo and it seems somebody is already working on it, here are some bugs awaiting for review. Bug 679096 Bug 738896 Bug 738897 So the question is, Is anybody out there is working on this, if so what stage are you on/can you provide a patch? Regards, rojanu _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Wed Apr 4 21:25:16 2012 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 04 Apr 2012 23:25:16 +0200 Subject: Bringing Testopia to up to Bugzilla 4.2 In-Reply-To: <6b4a8c89-e181-407d-9200-ed6b0b9f69f3@k14g2000vbe.googlegroups.com> References: <6b4a8c89-e181-407d-9200-ed6b0b9f69f3@k14g2000vbe.googlegroups.com> Message-ID: <4F7CBC3C.5060905@gmail.com> Le 03. 04. 12 21:13, rojanu a ?crit : > I just run a search on bmo and it seems somebody is already working on > it, here are some bugs awaiting for review. I reviewed them right now. Note that ghendricks is no longer around, since he left Novell. This means that Testopia has no active maintainer for more than a year. The last checkin was on March 2011. Without a new active maintainer, Testopia will die. The problem is that this prevents some Bugzilla installations from upgrading to 4.x, because they use Testopia to manage their testcases. rojanu: feel free to contribute by attaching patches, and coordinate your efforts with others by commenting in the bugs themselves. I will check what to do with Testopia. LpSolit From justdave at bugzilla.org Wed Apr 11 03:58:36 2012 From: justdave at bugzilla.org (David Miller) Date: Tue, 10 Apr 2012 23:58:36 -0400 Subject: bzr.mozilla.org Scheduled Maint 4/11 Message-ID: <4F85016C.1070402@bugzilla.org> Some of you may know that Mozilla is in the process of moving out of one of our datacenters in San Jose. Most of the stuff in that datacenter is moving to our new facility in Santa Clara. bzr.mozilla.org is currently hosted in San Jose, and its turn to move comes up tomorrow morning. I do not have an exact time for the outage, as it depends on when manpower is available (lots of things being moved) but it will be sometime on Wednesday, April 11, 2012, and it will last somewhere between 1 and 3 hours. The server is a virtual machine, and the machine's configuration and data files will be getting sent over the network to an ESX server at the new datacenter. How long it's down will depend on how long that file transfer takes. Part of the team working on this is on US East Coast hours, so it could start as early as 5am Pacific / 8am Eastern / 12pm UTC but could be later in the day, too. Sorry for any inconvenience. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Wed Apr 11 15:07:00 2012 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 11 Apr 2012 17:07:00 +0200 Subject: bzr.mozilla.org Scheduled Maint 4/11 In-Reply-To: <4F85016C.1070402@bugzilla.org> References: <4F85016C.1070402@bugzilla.org> Message-ID: <4F859E14.3080405@gmail.com> Le 11. 04. 12 05:58, David Miller a ?crit : > but it will be sometime on Wednesday, April 11, 2012, and it will last > somewhere between 1 and 3 hours. It's back again now, and is working fine. LpSolit From justdave at bugzilla.org Thu Apr 12 03:29:29 2012 From: justdave at bugzilla.org (David Miller) Date: Wed, 11 Apr 2012 23:29:29 -0400 Subject: [LISTADMIN] Migrating bugzilla.org mailing lists to Mailman Message-ID: <4F864C19.1070804@bugzilla.org> The details are at: https://bugzilla.mozilla.org/show_bug.cgi?id=628085 We've been meaning to do this for a long time, and faced with impending deadlines of losing the machine it's currently hosted on, now's a good time to go ahead and finish the job. This will probably be happening sometime in the next week. I'll post again when we have a specific date set. bugzilla.org's mailing lists are currently hosted in Majordomo2. This was a ground-up rewrite of Majordomo several years ago, which was both long overdue and way ahead of its time. Unfortunately, it hasn't been getting a lot of maintenance in recent years, never got a lot of the UI love it needed, and having never gotten an official release because of the developers being scared of having to do tech support, it never really took off. Every attempt will be made to preserve the subscriber lists, the archives, and the daily-vs-digest settings. Other individual settings you might have had on your subscription might be lost. You will probably get a welcome mail stating you've been subscribed via the new list manager, and that will include your new password for accessing the list manager's web interface. Majoromodo2 followed good practices and encrypted your passwords, so we have no way to migrate those. You're welcome to log in and change your password as soon as you receive the new one. The list headers will change. It is almost guaranted that you will need to adjust any mail filters you might have for identifying th emailing list traffic. The URL used to access the list manager will change, though we'll try to get a redirect in place for it from the old one. I'll announce the new URL after it exists (in the same announcement with the cutover date) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Fri Apr 13 07:41:52 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 13 Apr 2012 00:41:52 -0700 Subject: Password Hashes, Again Message-ID: <4F87D8C0.2090909@bugzilla.org> So, we probably shouldn't be using SHA at all, and we should switch to some Perl module that specifically is designed to do password hashing: http://www.codinghorror.com/blog/2012/04/speed-hashing.html tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From lpsolit at gmail.com Fri Apr 13 10:19:56 2012 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Fri, 13 Apr 2012 12:19:56 +0200 Subject: Password Hashes, Again In-Reply-To: <4F87D8C0.2090909@bugzilla.org> References: <4F87D8C0.2090909@bugzilla.org> Message-ID: <4F87FDCC.4020005@gmail.com> Le 13. 04. 12 09:41, Max Kanat-Alexander a ?crit : > tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs. It's interesting to see that the author of this post suddenly stops giving numbers when talking about salted-passwords. He just states that if the attacker could access your DB, he could also access your config file (in our case: localconfig). In that case, this defeats his whole theory, because the attacker doesn't need your password to read the whole DB and access all the data he wants. He is just saying that GPU gives you more power to try to crack a SHA-256 salted password, and he is right, but it's certainly by far much more difficult to crack than a non-salted password. And all his numbers were for non-salted MD5 passwords anyway, which we don't use. I wouldn't worry too much for now, at least not till someone can prove that SHA-256 salted-passwords are fast to crack (with real numbers). Else we are going to change our encryption algorithm every time someone writes a new article about security. :) LpSolit PS: the author suggests PBKDF2, but if you follow the link, it's written that "makes brute-force attacks using ASICs or GPUs relatively cheap". The other reference, bcrypt, seems to be weaker than scrypt against brute-force attacks. So we shouldn't jump in the game too quickly. From vladd at bugzilla.org Fri Apr 13 11:39:49 2012 From: vladd at bugzilla.org (Vlad Dascalu) Date: Fri, 13 Apr 2012 14:39:49 +0300 Subject: Password Hashes, Again In-Reply-To: <4F87FDCC.4020005@gmail.com> References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> Message-ID: > In that case, this defeats his whole > theory, because the attacker doesn't need your password to read the > whole DB and access all the data he wants. Passwords are encrypted in the DB to hide their actual value. In case a hacker gets access, salting passwords doesn't make their discovery any more difficult than it would be without it. 2012/4/13 Fr?d?ric Buclin : > Le 13. 04. 12 09:41, Max Kanat-Alexander a ?crit : >> ? ? ? tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs. > > It's interesting to see that the author of this post suddenly stops > giving numbers when talking about salted-passwords. He just states that > if the attacker could access your DB, he could also access your config > file (in our case: localconfig). In that case, this defeats his whole > theory, because the attacker doesn't need your password to read the > whole DB and access all the data he wants. He is just saying that GPU > gives you more power to try to crack a SHA-256 salted password, and he > is right, but it's certainly by far much more difficult to crack than a > non-salted password. And all his numbers were for non-salted MD5 > passwords anyway, which we don't use. > > I wouldn't worry too much for now, at least not till someone can prove > that SHA-256 salted-passwords are fast to crack (with real numbers). > Else we are going to change our encryption algorithm every time someone > writes a new article about security. :) > > LpSolit > > > PS: the author suggests PBKDF2, but if you follow the link, it's written > that "makes brute-force attacks using ASICs or GPUs relatively cheap". > The other reference, bcrypt, seems to be weaker than scrypt against > brute-force attacks. So we shouldn't jump in the game too quickly. > - > To view or change your list settings, click here: > From sdaugherty at gmail.com Fri Apr 13 15:54:22 2012 From: sdaugherty at gmail.com (Stephanie Daugherty) Date: Fri, 13 Apr 2012 11:54:22 -0400 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> Message-ID: How about a dynamic approach to hash strength - benchmark the hardware and increase the hash strength so that it always takes a particular amount of cpu time - therefore as hardware scales, so will the algorithm. On Apr 13, 2012 7:40 AM, "Vlad Dascalu" wrote: > > In that case, this defeats his whole > > theory, because the attacker doesn't need your password to read the > > whole DB and access all the data he wants. > > Passwords are encrypted in the DB to hide their actual value. In case > a hacker gets access, salting passwords doesn't make their discovery > any more difficult than it would be without it. > > 2012/4/13 Fr?d?ric Buclin : > > Le 13. 04. 12 09:41, Max Kanat-Alexander a ?crit : > >> tl;dr: You can break most SHA-256 passwords pretty quickly with > some GPUs. > > > > It's interesting to see that the author of this post suddenly stops > > giving numbers when talking about salted-passwords. He just states that > > if the attacker could access your DB, he could also access your config > > file (in our case: localconfig). In that case, this defeats his whole > > theory, because the attacker doesn't need your password to read the > > whole DB and access all the data he wants. He is just saying that GPU > > gives you more power to try to crack a SHA-256 salted password, and he > > is right, but it's certainly by far much more difficult to crack than a > > non-salted password. And all his numbers were for non-salted MD5 > > passwords anyway, which we don't use. > > > > I wouldn't worry too much for now, at least not till someone can prove > > that SHA-256 salted-passwords are fast to crack (with real numbers). > > Else we are going to change our encryption algorithm every time someone > > writes a new article about security. :) > > > > LpSolit > > > > > > PS: the author suggests PBKDF2, but if you follow the link, it's written > > that "makes brute-force attacks using ASICs or GPUs relatively cheap". > > The other reference, bcrypt, seems to be weaker than scrypt against > > brute-force attacks. So we shouldn't jump in the game too quickly. > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Apr 16 06:05:52 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 15 Apr 2012 23:05:52 -0700 Subject: Password Hashes, Again In-Reply-To: <4F87FDCC.4020005@gmail.com> References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> Message-ID: <4F8BB6C0.5020401@bugzilla.org> On 04/13/2012 03:19 AM, Fr?d?ric Buclin wrote: > It's interesting to see that the author of this post suddenly stops > giving numbers when talking about salted-passwords. He explains that salting them doesn't matter, because he's talking about brute-force numbers. It would take exactly the same amount of time to brute-force our salted hashes as it would to brute-force unsalted hashes. Salting is only to stop rainbow tables, which (as the author points out) are now less practical than brute force. > The other reference, bcrypt, seems to be weaker than scrypt against > brute-force attacks. So we shouldn't jump in the game too quickly. bcrypt has been around for a long time and is not possible to implement on GPUs. scrypt is a newer effort by the same authors and is not as well tested but is theoretically safer. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From mkanat at bugzilla.org Mon Apr 16 06:06:20 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 15 Apr 2012 23:06:20 -0700 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> Message-ID: <4F8BB6DC.7030807@bugzilla.org> On 04/13/2012 08:54 AM, Stephanie Daugherty wrote: > How about a dynamic approach to hash strength - benchmark the hardware > and increase the hash strength so that it always takes a particular > amount of cpu time - therefore as hardware scales, so will the algorithm. That wouldn't work; GPUs are cracking these things because they are massively parallel processors. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From gerv at mozilla.org Mon Apr 16 09:24:10 2012 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Apr 2012 10:24:10 +0100 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> Message-ID: <4F8BE53A.8050907@mozilla.org> On 16/04/12 07:05, Max Kanat-Alexander wrote: > He explains that salting them doesn't matter, because he's talking > about brute-force numbers. It would take exactly the same amount of time > to brute-force our salted hashes as it would to brute-force unsalted > hashes. Salting is only to stop rainbow tables, which (as the author > points out) are now less practical than brute force. Surely salting means you can only attack one password at once, whereas not salting means you can attack them all in parallel? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Mon Apr 16 11:05:59 2012 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 16 Apr 2012 13:05:59 +0200 Subject: Password Hashes, Again In-Reply-To: <4F8BB6C0.5020401@bugzilla.org> References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> Message-ID: <4F8BFD17.8070008@gmail.com> Le 16. 04. 12 08:05, Max Kanat-Alexander a ?crit : > about brute-force numbers. It would take exactly the same amount of time > to brute-force our salted hashes as it would to brute-force unsalted > hashes. I don't think that's true. At least not without knowing the salt first. LpSolit From vladd at bugzilla.org Mon Apr 16 11:38:56 2012 From: vladd at bugzilla.org (Vlad Dascalu) Date: Mon, 16 Apr 2012 14:38:56 +0300 Subject: Password Hashes, Again In-Reply-To: <4F8BFD17.8070008@gmail.com> References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> <4F8BFD17.8070008@gmail.com> Message-ID: > I don't think that's true. At least not without knowing the salt first. If he got access to the DB the assumption is that he knows the code for the salt (i.e. constant value or first two letters of the password being tried). > Surely salting means you can only attack one password at once, whereas not salting means you can attack them all in parallel? Salting has nothing to do with GPU parallelism. bcrypt fails on GPUs because it requires a long memory area which exceeds the addressable cache of the GPU units (see this answer: http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda ). From dberlin at dberlin.org Mon Apr 16 12:01:04 2012 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 16 Apr 2012 08:01:04 -0400 Subject: Password Hashes, Again In-Reply-To: <4F8BFD17.8070008@gmail.com> References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> <4F8BFD17.8070008@gmail.com> Message-ID: 2012/4/16 Fr?d?ric Buclin : > Le 16. 04. 12 08:05, Max Kanat-Alexander a ?crit : >> about brute-force numbers. It would take exactly the same amount of time >> to brute-force our salted hashes as it would to brute-force unsalted >> hashes. > > I don't think that's true. At least not without knowing the salt first. > > LpSolit Most salts are stored along with the password database. The point of having a salt is to make lookup tables expensive to compute, not to be secret. From dberlin at dberlin.org Mon Apr 16 12:01:50 2012 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 16 Apr 2012 08:01:50 -0400 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> <4F8BFD17.8070008@gmail.com> Message-ID: On Mon, Apr 16, 2012 at 7:38 AM, Vlad Dascalu wrote: >> I don't think that's true. At least not without knowing the salt first. > > If he got access to the DB the assumption is that he knows the code > for the salt (i.e. constant value or first two letters of the password > being tried). > >> Surely salting means you can only attack one password at once, whereas not salting means you can attack them all in parallel? > > Salting has nothing to do with GPU parallelism. bcrypt fails on GPUs > because it requires a long memory area which exceeds the addressable > cache of the GPU units ?(see this answer: > http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda > ). Of course, this will change as effects/etc GPU's are used for become ever more complex. I wouldn't expect this particular limitation to last for very long. It was only a short time ago that GPU's basically had *no* local ram. From vladd at bugzilla.org Mon Apr 16 12:12:30 2012 From: vladd at bugzilla.org (Vlad Dascalu) Date: Mon, 16 Apr 2012 15:12:30 +0300 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> <4F8BFD17.8070008@gmail.com> Message-ID: > Of course, this will change as effects/etc GPU's are used for become > ever more complex. > I wouldn't expect this particular limitation to last for very long. > It was only a short time ago that GPU's basically had *no* local ram. Due to paralelization, it's much more expensive for them to match our RAM requirements: There's nothing which prevents us from implementing a hash computation algorithm requiring 20 MB of addressable RAM for each login procedure, and this would be a show-stopper for most attackers as they cannot afford that much RAM per individual worker. From dberlin at dberlin.org Mon Apr 16 12:43:39 2012 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 16 Apr 2012 08:43:39 -0400 Subject: Password Hashes, Again In-Reply-To: References: <4F87D8C0.2090909@bugzilla.org> <4F87FDCC.4020005@gmail.com> <4F8BB6C0.5020401@bugzilla.org> <4F8BFD17.8070008@gmail.com> Message-ID: On Mon, Apr 16, 2012 at 8:12 AM, Vlad Dascalu wrote: >> Of course, this will change as effects/etc GPU's are used for become >> ever more complex. >> I wouldn't expect this particular limitation to last for very long. >> It was only a short time ago that GPU's basically had *no* local ram. > > Due to paralelization, it's much more expensive for them to match our > RAM requirements: There's nothing which prevents us from implementing > a hash computation algorithm requiring 20 MB of addressable RAM for > each login procedure, and this would be a show-stopper for most > attackers as they cannot afford that much RAM per individual worker. It would be a mistake to assume someone "cannot afford" that much ram within the reasonable lifetime of your program DRAM cost/bit drops by about 30-40% a year (according to ITRS). Their reports/numbers have been consistent over the years. (ITRS reports are not always available to the public without paying, but i can get you this one page/table if you want to see it) Here's how many bits you could afford per dollar, rounded out: 2009 - 200000000 - cost 0.48 microcents per bit 2010 - 294000000 - cost 0.34 microcents per bit 2011 - 417000000 - cost 0.24 microcents per bit 2012 - 588000000 - cost 0.17 microcents per bit 2013 - 833000000 - cost 0.12 microcents per bit - cost would be 100 bucks to add 20 meg to 500 cores ... in 2017, the number of bits per dollar will be 3330000000 - cost would be 25 bucks to add 20 meg to 500 cores Note that even if you update your hash method every 5 years to account for technology, plenty of folks will be vulnerable for a while until they upgrade. From Nick.Barnes at pobox.com Mon Apr 16 13:07:39 2012 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 16 Apr 2012 14:07:39 +0100 Subject: Password Hashes, Again In-Reply-To: from Daniel Berlin of "Mon, 16 Apr 2012 08:43:39 -0400" Message-ID: <38798.1334581659@thrush.ravenbrook.com> At 2012-04-16 12:43:39+0000, Daniel Berlin writes: > DRAM cost/bit drops by about 30-40% a year (according to ITRS). There are good reasons, acknowledged by the ITRS, to suppose that a number of these long-term exponential trends are going to peter out over the next decade. Nick B From dberlin at dberlin.org Mon Apr 16 13:10:41 2012 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 16 Apr 2012 09:10:41 -0400 Subject: Password Hashes, Again In-Reply-To: <38798.1334581659@thrush.ravenbrook.com> References: <38798.1334581659@thrush.ravenbrook.com> Message-ID: On Mon, Apr 16, 2012 at 9:07 AM, Nick Barnes wrote: > At 2012-04-16 12:43:39+0000, Daniel Berlin writes: > >> DRAM cost/bit drops by about 30-40% a year (according to ITRS). > > There are good reasons, acknowledged by the ITRS, to suppose that a > number of these long-term exponential trends are going to peter out > over the next decade. Entirely true. However, to bring things back around, it will not likely peter out before it's cheap to put large lookup tables on GPU's. From knocte at NOSPAMPLEASE-gmail.com Tue Apr 17 12:46:44 2012 From: knocte at NOSPAMPLEASE-gmail.com (Andres G. Aragoneses) Date: Tue, 17 Apr 2012 13:46:44 +0100 Subject: BrowserID? Message-ID: Just saw today that BMO has already integrated BroswerID, kudos! So, does anybody here know if there are plans to integrate this in bugzilla upstream? Thanks _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Tue Apr 17 15:48:51 2012 From: glob at mozilla.com (Byron Jones) Date: Tue, 17 Apr 2012 08:48:51 -0700 Subject: BrowserID? In-Reply-To: References: Message-ID: <4F8D90E3.10307@mozilla.com> Andres G. Aragoneses wrote: > Just saw today that BMO has already integrated BroswerID, kudos! > So, does anybody here know if there are plans to integrate this in > bugzilla upstream? browserid integration is done with a bugzilla extension, so it's available for deployment on other installs. it's doubtful this will be integrated into the upstream code imho. http://bzr.mozilla.org/bugzilla/extensions/browserid/trunk/files -- byron - irc:glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From knocte at NOSPAMPLEASE-gmail.com Tue Apr 17 21:24:07 2012 From: knocte at NOSPAMPLEASE-gmail.com (Andres G. Aragoneses) Date: Tue, 17 Apr 2012 22:24:07 +0100 Subject: BrowserID? In-Reply-To: References: Message-ID: <4qWdnZyq7YzpQhDSnZ2dnUVZ_radnZ2d@mozilla.org> On 04/17/2012 04:48 PM, Byron Jones wrote: > Andres G. Aragoneses wrote: >> Just saw today that BMO has already integrated BroswerID, kudos! >> So, does anybody here know if there are plans to integrate this in >> bugzilla upstream? > browserid integration is done with a bugzilla extension, so it's > available for deployment on other installs. > it's doubtful this will be integrated into the upstream code imho. > > http://bzr.mozilla.org/bugzilla/extensions/browserid/trunk/files > Cool, that's the info I needed. Thanks! _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From khokhar_cth at live.com Wed Apr 18 13:40:45 2012 From: khokhar_cth at live.com (Khokhar cth) Date: Wed, 18 Apr 2012 15:40:45 +0200 Subject: Bugzilla code help require Message-ID: Hi, I need your assistance about bugzilla. I have some productsProductA ProductB and groups in bugzilla.Client Developer Only Developer should able the create/edit the fields but Client should not able to edit the bug.The following discussion was very helpful for me.http://groups.google.com/group/netscape.public.mozilla.webtools/browse_thread/thread/98efcae88fe84d6d/51c8deb672402e09?lnk=gst&q=permissions+for+all+users#51c8deb672402e09 Answer:Product A:ReadCreateA: Entry/Mandatory/Mandatory/-- EditA: --/NA/NA/Canedit Similar for Product B.For this, you need to give editbugs privileges to developers. If you want to restrict editbugs privileges in other products, you need to set up a group they are not a member of as xx/xx/xx/Canedit for the other products. In your particular setup, this is already covered by the EditA and EditB groups.(Works fine ) When I use the above guide , it works perfectly except posting comments. I am getting following error while posting comment --> "You are not permitted to edit bugs in product Product A" but I want users of "Group UsersA" should not edit the bug (that is fine) but must be able to post the comment. What to do ? I am thinking to change the code of bugzilla, I am using 3.6.3. But i don't know after submit the bug where this form will post and where i'll catch the request ? is it Bug.pl file? bug page url is http://localhost/show_bug.cgi?id=8 and after submitting it becomes http://localhost/process_bug.cgi with following Error msg "You are not permitted to edit bugs in product Product A". I am thinking to to catch the
request and write the if condition for following text area. is it possible ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Apr 27 09:42:49 2012 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 27 Apr 2012 10:42:49 +0100 Subject: Extension architecture help required Message-ID: Hi, In my Sync extension: http://bzr.mozilla.org/bugzilla/extensions/sync/ I am using the bug_end_of_update hook to do syncing once a bug is updated. However, in the current implementations of sync clients, I sync asynchronously, to avoid blocking the main execution. So what happens is that a job gets added to the job queue which does the sync for that bug, and some time later the job gets pulled off and run. One of the job parameters is the bug ID, because the jobqueue system Stores (using Storable) its parameters, and it doesn't like Storing the entire updated bug object. So I pass the ID and recreate the object using new Bugzilla::Bug($id); This is normally fine, because the job queue comes with a bit of a delay built in. However, bug_end_of_update runs inside a transaction. If the job gets pulled off the queue and run before the transaction completes (which is perhaps more likely if a bug is part of a large batch update, all of which share a transaction - see process_bug.cgi) then when the syncing job recreates the bug object, it gets stale data. And the wrong data gets sent to the remote system. How can I avoid this? Ideally I want a generic solution, such that the "something's changed" event isn't even triggered until the database has been updated. But there's no hook for that, and there isn't an obvious place to add one. Otherwise, is there some way my code can wait for the transaction to complete? Problem is, it would need to do so in each individual syncing job implementation, which is an implementation detail I'd hope to hide. Ideas welcome! Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Mon Apr 30 02:27:21 2012 From: glob at mozilla.com (Byron Jones) Date: Mon, 30 Apr 2012 10:27:21 +0800 Subject: Extension architecture help required In-Reply-To: References: Message-ID: <4F9DF889.8030706@mozilla.com> hey gerv, Gervase Markham wrote: > In my Sync extension: > http://bzr.mozilla.org/bugzilla/extensions/sync/ > I am using the bug_end_of_update hook to do syncing once a bug is > updated. i have an extension which is designed to push updates to other systems which currently poll bugzilla for updates (pulse, elastic search caches, metrics, etc). https://github.com/globau/bugzilla-push it's extremely close to completion, and is a q2 goal. i deal with the issue you've encountered by performing serialisation of the bug at the time the update is made, in my case to JSON. these are inserted into a custom table which a custom daemon polls and sends. i don't use the jobqueue system because that doesn't guarantee the order of the messages, which is important when you're sending update messages (especially when a remote system is down). since i already have a working system for sending bug updates which deals correctly with ordering of the updates, as well as queuing messages when the remote system is down, another option would be for the update-pushing part of your extension to utilise my bugzilla-push extension and be dropped in as another connector. see https://github.com/globau/bugzilla-push/tree/master/Push/lib/Connector -byron -- byron - irc:glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Apr 13 07:41:52 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 13 Apr 2012 00:41:52 -0700 Subject: Password Hashes, Again Message-ID: <4F87D8C0.2090909@bugzilla.org> So, we probably shouldn't be using SHA at all, and we should switch to some Perl module that specifically is designed to do password hashing: http://www.codinghorror.com/blog/2012/04/speed-hashing.html tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ - To view or change your list settings, click here: _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From Nick.Barnes at pobox.com Mon Apr 16 13:07:39 2012 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 16 Apr 2012 14:07:39 +0100 Subject: Password Hashes, Again In-Reply-To: from Daniel Berlin of "Mon, 16 Apr 2012 08:43:39 -0400" Message-ID: <38798.1334581659@thrush.ravenbrook.com> At 2012-04-16 12:43:39+0000, Daniel Berlin writes: > DRAM cost/bit drops by about 30-40% a year (according to ITRS). There are good reasons, acknowledged by the ITRS, to suppose that a number of these long-term exponential trends are going to peter out over the next decade. Nick B - To view or change your list settings, click here: _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla