Re: failure notice
On 30 Nov 2010, at 12:49, Noah Slater wrote: > Check out this ticket: > > https://issues.apache.org/jira/browse/COUCHDB-937 > Ok - the first step in the bounce cycle seems to be through an address of alan.mo...@barclaysglobal.com. I won't have apmail/ssh access for the next hours - so if someone can unsubscribe that address - much appreciated ! Thanks, Dw.
Re: failure notice
On 30 Nov 2010, at 12:44, Noah Slater wrote: > Not this ing thing again. > This problem caused like twelfty bazillion comments to be left in JIRA a few > weeks ago. > I thought they'd been blacklisted? I did a quick trace - and this bounce may be one step away from us - so the blacklist sort of does not help - as it bypasses ASF infra. Thanks, Dw
Re: failure notice
On 30 Nov 2010, at 11:47, Dirk-Willem van Gulik wrote: > > On 30 Nov 2010, at 11:41, Robert Dionne wrote: > >> I also received this when I forwarded your reply to my post to >> dev.apache.org. > >>> Please note that the address: >>> dev@couchdb.apache.org >>> will cease working on December 1, 2010. Please update your contact address >>> to the same address @blackrock.com. > > You may want to do a quick 'dig mx couchdb.apache.org' and 'dig mx > apache.org' and then hop onto IRC to talk to the #asfinfra folks (or drop > them an email). But given the results I get from above MX information - my > first guess would be some issue local to your infrastructure - in particular > a misconfiguration at 'blackrock' seems most likely. Grin - I got a bouncer as well - so that makes the most likely scenario that someone on this lists is processed through blackrock.com - and that is what causes the backscatter. I'll do a quick trace if this does not disappear in the next 48 hours - and will them notify that person. Dw.
Re: failure notice
On 30 Nov 2010, at 11:41, Robert Dionne wrote: > I also received this when I forwarded your reply to my post to dev.apache.org. >> Please note that the address: >>dev@couchdb.apache.org >> will cease working on December 1, 2010. Please update your contact address >> to the same address @blackrock.com. You may want to do a quick 'dig mx couchdb.apache.org' and 'dig mx apache.org' and then hop onto IRC to talk to the #asfinfra folks (or drop them an email). But given the results I get from above MX information - my first guess would be some issue local to your infrastructure - in particular a misconfiguration at 'blackrock' seems most likely. Dw
Re: export control notice - multiview
On 29 Jul 2010, at 04:55, Norman Barker wrote: > I work for ITT VIS and we would really like to give this multiview for > consideration by the community (as well as other patches)*. I have > passed this to our legal dept and they would like us to follow > http://www.apache.org/dev/crypto.html, I believe this has already been > followed since Damien has his name on the XML below as PMC chair. Have a look at: http://www.apache.org/licenses/exports/ > Whatever procedure Damien followed should be documented so that other > US companies can contribute. I believe that all is sufficient is a Please see http://www.apache.org/dev/crypto.html > paper trail to show that the necessary govt depts have been notified > about cryptography (in this case SSL) components in the software. If the entry is there - http://www.apache.org/licenses/exports/ you can be sure that the PMC followed the right path and that this is under the normal oversight by the board of the foundation. And the board is to oversee that PMCs keep doing this right; and PMCs are to ensure their area's are all doing the right things; and that each release has its t's crossed and i's dotted. Or in other words - you have confirmation that the legal entity responsible (the ASF) has, and is, carrying out the right steps. Every time a release is rolled - it is the PMCs tasks to oversee that - and specifically they are expected to keep an eye on the correctness of above corporate records; and bring them up to date if needed. It is very good practice to alert the Dev community and the PMC when doing contributions such as this; as the process described on http://www.apache.org/dev/crypto.html titled 'Check the Export Control Classification Number (ECCN)' with regard to qualification under 740.13(e) as ECCN 5D002 is not trivial (though it does over a large swath). And if a project is particularly worried, say because it has a lot of small moving crypto, you could simply add a step to your release process which says 're-evaluate ECCN qualification if any crypto code was added or changed relative to prior releases'. But in this case - the PMC seems to have this well under control and releases get their i's dotted and t's crossed. Thanks, Dw. *: I am skipping the usual verbiage on CCLA and/or iCLA being on file, etc.
Re: Making CouchDB crypto dependency optional
On 18 Jan 2010, at 19:24, Jonathan wrote: > That aside, it's quite slow... a better option would be to implement the SHA > portions (from spec alone) in C/++ and access them using Erlang ports. I > You may be able to simply cut and paste in code from http://svn.apache.org/repos/asf/apr/apr/trunk/crypto/apr_sha1.c or link/call against APR. Dw http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. smime.p7s Description: S/MIME cryptographic signature
Re: Making CouchDB crypto dependency optional
On 18 Jan 2010, at 19:34, Nathan Stott wrote: > This stack overflow answer suggests that this is not CC-By-SA: > http://stackoverflow.com/questions/244898/wikipedia-pseudocode-and-ip > While I'd agree that there are cases where that is indeed the case - I think you are not doing justice to this specific case - and which is fairly gray. It does 1) not pass the test that it is the the only and essential means to accomplish a task (compare that code to the original NIST code) - nor 2) does it pass the 'impossible to write differently' test. And keep in mind that outside the US the barrier is set differently. So I think you want to treat this as neither black or white - but look at the context - and thus keep in mind the likely intentions of the wikipedia authors along with the risk/reward profile in this specific case (easy to swap, used rarely, ASF does not make any money, etc). Or simply 'punt' - and swap in the IEFT code. Thanks, Dw http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. smime.p7s Description: S/MIME cryptographic signature
Re: Making CouchDB crypto dependency optional
On Mon, Jan 18, 2010 at 1:23 AM, Jonathan wrote: > On Sun, Jan 17, 2010 at 11:31 PM, Dirk-Willem van Gulik < > dirk-willem.van.gu...@bbc.co.uk> wrote: >> Sorry - that is the algorithm - not the *implementation*. >> If you wrote it from scratch - just using documents like above - then you >> are good (and all that is needed is a software grant from you - or a >> contribution under a CLA - and point to the document as the source.). > Excellent, thanks very much for the clarification - I'm thoroughly > inexperienced when it comes to licensing. My code was based off of > pseudocode listed on Wikipedia and so (I believe) would fall under the > CC-BY-SA license - I've updated the Jira issue as appropriate. Thank you > for catching this early. If you take a very firm black and white stance - completely agreed. You could do three things: - Rewrite it based on http://www.ietf.org/rfc/rfc3174.txt or http://www.itl.nist.gov/fipspubs/fip180-1.htm. - Abide by the CC-by-SA which is apache compatible enough and cut-and-paste in all the legal verbiage - that just adds a lot of silly bytes to the overall code though. - Convince the PMC that this is a sufficiently grey case where you fairly used a scholarly work or encyclopedia to base your code on - and then fudge it a bit with a link to the CC-by-SA and the wiki page - also given the fact that the likelihood of 1) an issue is small and 2) would propably feel that a /* comment */ with a pointer to the right wiki page is what they would expect. As they license/manage knowledge rather than control running code. I think this is a perfectly gray case - and you should be able to get away with each - the PMC can make the ultimate call. Thanks, Dw. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. smime.p7s Description: S/MIME cryptographic signature
Re: Making CouchDB crypto dependency optional
On 17 Jan 2010, at 22:08, Chris Anderson wrote: > On Sun, Jan 17, 2010 at 1:17 PM, Jonathan wrote: >> source difficult. A grep through the CouchDB 0.10.1 source shows that there >> are 5 actual calls into the crypto library, calling the functions: start/0, >> sha/1, rand_bytes/1, rand_uniform/2, and sha_mac/2. >> >> I've created a pure-Erlang copy of this API (that attempts to fallback to >> the crypto library if possible) at http://gist.github.com/279085. The >> random stream isn't cryptographically secure of course, but it should work >> for generating UUIDs... > I'm +1 on this. The complications are (a) making sure the licensing is > done correctly. (b) > making sure the sha etc are compatible, so passwords work across > implementations. Can you folks make sure you spend some serious cycles on having test cases ? Over the years I've been bitten more than once by things like this - where at some point later something like a sha1 suddenly was used for a digest or similar - and had to be bit-for-bit compatible. Likewise - you probably want to strongly document each call to the rand_*/2 (in the calling code) to warn/document the assumption that what is returned is no longer properly* random. Thanks, Dw. *: insert appropriate def of cryptographically unpredictable, etc. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: Making CouchDB crypto dependency optional
On 18 Jan 2010, at 01:06, Jonathan wrote: > I've updated the gist to include (along with fixes thanks to said testing) > the test_sha/1 and test_sha_mac/1 functions, which will test random messages ... > As for the licensing, I'm definitely not a lawyer. For what it's worth, the > reference implementation was published in RFC 3174, which in turn draws > mostly from NIST FIPS 180-1, which was superseded by FIPS 180-2. According > to https://datatracker.ietf.org/ipr/858/: Sorry - that is the algorithm - not the *implementation*. If you wrote it from scratch - just using documents like above - then you are good (and all that is needed is a software grant from you - or a contribution under a CLA - and point to the document as the source.). HOWEVER if you took some random piece of existing code and 'erlangfied' it; or cut-and-pasted, say, C, Perl, Java or other third party existing code into it - and then massaged that to work *then* you have to be significantly more careful. There are then 4 cases: - You only took one or two lines from someone else their code 'in total' as a starting point. - You took some lines from code under a BSD, ASL or similar 'open' license (e.g. say from APR or from OpenSSL itself). - You took code from a GPL, LGPL or similar family of code. - You took code which someone (you perhaps) once wrote for a company. In the first two cases; no problem - just document where you took it and point to the license as needed. In the third case - big no-no; in the final case - better get permission from the person who paid you. As to 'recognizing' this - you'd be surprized how unique certain spaces/variable name and orderings are - and how many permutations are possible - or in other words - how long the 'fingerprint' of a given original last through cut and paste. Thanks, Dw. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
FOSDEM (Was: CouchDB speakers)
Speaking of this - who is planning to go to fosdem (www.fosdem.org; brussels, in a months time) ? Thanks, Dw. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: Reporting potential security issues
On 19 Dec 2009, at 21:11, Noah Slater wrote: > Do we have a secur...@couchdb.apache.org? Who is on that list? If nothing is set up/asked for - it generally goes to pmc@ and cc security@ - but not all groups have asked for anything/set anything up. I guess it is about time to consider as developers how you want to handle this and/or have a group of developers step up to timely act on the rare but important security@ reports. And commit to do so in a timely manner. Dw http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: Reporting potential security issues
On 19 Dec 2009, at 17:19, Florian Weimer wrote: > What are your preferences for reporting potential security issues? > Shall I post them here, open a bug, or send them through > ? If it is quite sensitive - please post to secur...@apaache.org; use pgp if/as needed. We'll pass it on to the developers in private. See http://www.apache.org/security/committers.html for more details. Then security@.org is the next level down (which auto cc to secur...@apache.org) - or feel free to consults the AUTHORS file to directly mail the right developer - but do cc in secur...@apache.org org. If it not very sensitive - dev is fine. Do note that security@ usually also trigger CVE and similar escalation if not yet done. Shoot me or security@ a private mail if you need a hand with a judgment all. Thanks, Dw. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: Statistics Module
Paul Davis wrote: >> The way that stats are calculated currently with the dependent >> variable being time could cause some issues in implementing more >> statistics. With my extremely limited knowledge of stats I think >> moving that to be dependent on the number of requests might be better. Code looks awesome. For reference, they're storing the last N samples with each time point over a given time period. Ie, they store the current counter values once a second. Eh - do you really want to build RRDtool/cacti/nagios/zenoss/mrtg like capabilities in your database ? I'd say - focus on getting the data out (ideally as _counters_) and let the monitoring tools figure out the rest. They know their polling intervals and what not (some dynimically adjust) and can figure out how to sample, calculate rates, do stats and what not. And can have fairly refined windowing techniques to aggregate (e.g. rrdtool). So do not try to make a stats module - try to make a module that output the data on which you can base your starts :). I.e. when you can have: database_opened counter database_closed counter you can work out 1) rate of open/close, 2) the number currently open and do all sorts of post processing. Whereas a float giving you some rate over some unknown window is not nearly as useful. Dw http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
