Return-Path: 
 <derby-dev-return-24204-apmail-db-derby-dev-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: (qmail 27664 invoked from network); 17 Jul 2006 19:01:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Jul 2006 19:01:23 -0000
Received: (qmail 97393 invoked by uid 500); 17 Jul 2006 19:01:22 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 97361 invoked by uid 500); 17 Jul 2006 19:01:22 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:derby-dev-help@db.apache.org>
List-Unsubscribe: <mailto:derby-dev-unsubscribe@db.apache.org>
List-Post: <mailto:derby-dev@db.apache.org>
List-Id: <derby-dev.db.apache.org>
Reply-To: <derby-dev@db.apache.org>
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 97352 invoked by uid 99); 17 Jul 2006 19:01:22 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 12:01:22 -0700
X-ASF-Spam-Status: No, hits=0.5 required=10.0
	tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of francois.orsini@gmail.com
 designates 64.233.182.185 as permitted sender)
Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 12:01:21 -0700
Received: by nf-out-0910.google.com with SMTP id m19so34474nfc
        for <derby-dev@db.apache.org>; Mon, 17 Jul 2006 12:01:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=KCfDAdyS4zbd5jF3FBPNf/KR/Mk7jO1HuTaDoVPDfyPRHdnyF+vRBdZdeSAl1Yf22N7rP6P3er+GTvS6BIsk07lJn42z79o83OVAfxHjO586pmFhA80Mv4f66/e4tkZlZhQeyD1s8zgxosGTkNBreeAKZD11nuEuAls0FElOA+U=
Received: by 10.48.210.20 with SMTP id i20mr2246331nfg;
        Mon, 17 Jul 2006 12:01:00 -0700 (PDT)
Received: by 10.48.207.16 with HTTP; Mon, 17 Jul 2006 12:00:59 -0700 (PDT)
Message-ID: <7921d3e40607171200l47bc3279ub705a719ae22b25@mail.gmail.com>
Date: Mon, 17 Jul 2006 12:00:59 -0700
From: "Francois Orsini" <francois.orsini@gmail.com>
To: derby-dev@db.apache.org
Subject: DERBY-528 - IRC discussion summary between KatheyM and FrancoisO
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_65004_28341591.1153162859496"
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

------=_Part_65004_28341591.1153162859496
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is a summary of the IRC discussion Kathey M. and I had today. Posting
it on derby-dev to record it - Thanks again for your time and help Kathey.

    <kmarsden>    francois: Did you want to talk about DERBY-528? We can
talk here on #derby and then summarize to the list.
    <FrancoisOrsini>    I'm going to post some details as you've asked
    <kmarsden>    The big question for me is that I want to make sure this
doesn't cause any new upgrade order restrictions
    <FrancoisOrsini>    It should not with the current changes
    <kmarsden>    10.1 /10.2 servers/clients need to continue to work
together without change. Even if it is that the DERBY-528 fix exposes an
existing but, it needs to be resolved before DERBY-528 goes in.
    <kmarsden>    Does that make sense?
    <FrancoisOrsini>    Absolutely
    <kmarsden>    Oh sorry, then I am confused about your original question
    <FrancoisOrsini>    ok - let me explain
    <kmarsden>    not question, statement about the incompatibility.
    <FrancoisOrsini>    The current changes as they have been posted do not
cause 10.1 /10.2 servers/clients connection(s) to fail - all compatibility
tests are passing
    <kmarsden>    ok. You made a code change then to do that from your
original patch?
    <FrancoisOrsini>    Yes I did
    <FrancoisOrsini>    I have backed out the default upgraded secmec to use
as SECMEC_USRSSBPWD (password substitute)
    <FrancoisOrsini>    Because we can't process on the client the list of
SecMec's returned from a server which does not support this new SecMec
(SECMEC_USRSSBPWD)
    <FrancoisOrsini>    For instance, 10.2 <--> 10.1
    <kmarsden>    I see I really missed that from your patch update
description.
    <FrancoisOrsini>    If I could parse that list on the client side, then
SECMEC_USRSSBPWD could be used as a default upgraded secmec after
SECMEC_EUSRIDPWD for instance
    <FrancoisOrsini>    Yes, sorry my description was not clear
    <FrancoisOrsini>    Hence why I entered
http://issues.apache.org/jira/browse/DERBY-1517
    <kmarsden>    Then after the fix for DERBY-1517 you will be able to
reenable?
    <FrancoisOrsini>    Yep
    <FrancoisOrsini>    and It was working great until I ran the full
compatibility tests
    <FrancoisOrsini>    I had run lots of tests w/ SECMEC_USRSSBPWD so I
know it had been working fine, except when going 10.2 --> 10.1
    <kmarsden>    I understand. I was wondering if you could post a summary
of the changes that the DERBY-528 patch makes in some detail to make it a
little easier to review.
    <FrancoisOrsini>    Yes am writing it now
    <FrancoisOrsini>    But Derby-1517 is tricky
    <kmarsden>    Excellent. I will wait for that and then review.
    <FrancoisOrsini>    The server version is not returned from a ACCSECRD
:(
    <kmarsden>    Right. I was worried about that. It is too early right?
    <FrancoisOrsini>    I have to recheck again but I did not see it - Yes
it is too early as you mentioned in the notes
    <FrancoisOrsini>    But then am trying to see if I could still parse the
list returned today, instead of the array (as the specs mentioned)
    <kmarsden>    good. It would be good to upgrade the default.
    <FrancoisOrsini>    Absolutely - This was my original intention and
changes
    <FrancoisOrsini>    This security mechanism implementation has ben a
challenging one
    <kmarsden>    Thanks for taking it on. On the coding format. The only
place I saw the indentation not matching the surrounding code was
BasicAuthenticationServiceImpl with a visual diff.
    <FrancoisOrsini>    Due to the fact, well, there is no way to decrypt a
substituted (hashed) password :)
    <FrancoisOrsini>    Ok - I'm going to look at these and address them
    <kmarsden>    It is awful that we don't have a coding standard
    <FrancoisOrsini>    Yeah and then it is hard to copy code that does not
look standard when you need to put new changes - am always tempted to fix
code around but then it is confusing the review
    <FrancoisOrsini>    Need to ask you something about db2jcc
    <FrancoisOrsini>    what is 2.6 and 2.8 under master\DerbyNet
    <kmarsden>    Someone will eventually get sick of it and pick up
DERBY-1363. every new developer gets bitten by that bug.
    <kmarsden>    Yes. They are JCC versions. What JCC version are you
using?
    <FrancoisOrsini>    Am using 2.4
    <kmarsden>    OK. When you post your summary comment. Just add that JCC
2.6, 2.8 also need to be updated and ask if someone with access can update
the masters.
    <kmarsden>    I can probably do it as part of my review.
    <FrancoisOrsini>    ok I will ask
    <FrancoisOrsini>    Thanks for your time Kathey
    <kmarsden>    Thank you Francois.

Cheers,

--francois

------=_Part_65004_28341591.1153162859496
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is a summary of the IRC discussion Kathey M. and I had today.
Posting it on derby-dev to record it - Thanks again for your time and
help Kathey.<br>
<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; francois: Did you
want to talk about DERBY-528? We can talk here on #derby and then
summarize to the list.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; I'm going to post some details as you've asked<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; The big question
for me is that I want to make sure this doesn't cause any new upgrade
order restrictions<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; It should not with the current changes<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; 10.1 /10.2
servers/clients need to continue to work together without change. Even
if it is that the DERBY-528 fix exposes an existing but, it needs to be
resolved before DERBY-528 goes in.<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Does that make sense?<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Absolutely<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Oh sorry, then I am confused about your original question<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; ok - let me explain<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; not question, statement about the incompatibility.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; The current
changes as they have been posted do not cause 10.1 /10.2
servers/clients connection(s) to fail - all compatibility tests are
passing<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; ok. You made a code change then to do that from your original patch?<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Yes I did<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; I have
backed out the default upgraded secmec to use as SECMEC_USRSSBPWD
(password substitute)<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Because we
can't process on the client the list of SecMec's returned from a server
which does not support this new SecMec (SECMEC_USRSSBPWD)<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; For instance, 10.2 &lt;--&gt; 10.1<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; I see I really missed that from your patch update description.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; If I could
parse that list on the client side, then SECMEC_USRSSBPWD could be used
as a default upgraded secmec after SECMEC_EUSRIDPWD for instance<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Yes, sorry my description was not clear<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Hence why I entered <a href="http://issues.apache.org/jira/browse/DERBY-1517">http://issues.apache.org/jira/browse/DERBY-1517</a><br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Then after the fix for DERBY-1517 you will be able to reenable?<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Yep<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; and It was working great until I ran the full compatibility tests<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; I had run
lots of tests w/ SECMEC_USRSSBPWD so I know it had been working fine,
except when going 10.2 --&gt; 10.1<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; I understand. I
was wondering if you could post a summary of the changes that the
DERBY-528 patch makes in some detail to make it a little easier to
review.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Yes am writing it now<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; But Derby-1517 is tricky<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Excellent. I will wait for that and then review.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; The server version is not returned from a ACCSECRD :(<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Right. I was worried about that. It is too early right?<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; I have to
recheck again but I did not see it - Yes it is too early as you
mentioned in the notes<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; But then am
trying to see if I could still parse the list returned today, instead
of the array (as the specs mentioned)<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; good. It would be good to upgrade the default.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Absolutely - This was my original intention and changes<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; This security mechanism implementation has ben a challenging one<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Thanks for taking
it on. On the coding format. The only place I saw the indentation not
matching the surrounding code was BasicAuthenticationServiceImpl with a
visual diff.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Due to the
fact, well, there is no way to decrypt a substituted (hashed) password
:)<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Ok - I'm going to look at these and address them<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; It is awful that we don't have a coding standard<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Yeah and
then it is hard to copy code that does not look standard when you need
to put new changes - am always tempted to fix code around but then it
is confusing the review<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Need to ask you something about db2jcc<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; what is 2.6 and 2.8 under master\DerbyNet<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Someone will
eventually get sick of it and pick up DERBY-1363. every new developer
gets bitten by that bug.<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Yes. They are JCC versions. What JCC version are you using?<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Am using 2.4<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; OK. When you post
your summary comment. Just add that JCC 2.6, 2.8 also need to be
updated and ask if someone with access can update the masters.<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; I can probably do it as part of my review.<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; ok I will ask<br>
&nbsp;&nbsp;&nbsp; &lt;FrancoisOrsini&gt;&nbsp;&nbsp;&nbsp; Thanks for your time Kathey<br>
&nbsp;&nbsp;&nbsp; &lt;kmarsden&gt;&nbsp;&nbsp;&nbsp; Thank you Francois.<br>
<br>
Cheers,<br>
<br>
--francois<br>

------=_Part_65004_28341591.1153162859496--