Re: Release?
Changes complete.
This was helpful in that it found a bug in the sql generated for
PostgreSQL for two of the history reports. Aside from that, I still
believe this is more of a precaution than a necessity.
Karl
On Mon, Dec 6, 2010 at 8:35 PM, Karl Wright wrote:
> Here is a list of the pertinent places where quoteSQLString is used.
> Note that EXCEPT in a couple of cases where quoteSQLString was needed
> to furnish an argument for a clause being formed by a database
> abstraction method, ALL other cases are quoting of constant values,
> save in one case, which I am happy to change.
>
>>>
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/Jobs.java
> getTableName()+" WHERE
> "+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE))+
> " AND
> "+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE_NOOUTPUT))+
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")
> "+constructOffsetLimitClause(0,1),null,null,null,1);
> statusField+" IN
> ("+quoteSQLString(statusToString(STATUS_READYFORDELETE))+","+
> quoteSQLString(statusToString(STATUS_SHUTTINGDOWN))+")
> "+constructOffsetLimitClause(0,1),
> quoteSQLString(statusToString(STATUS_ACTIVE)) + "," +
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING)) +
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobManager.java
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))+
> " AND
> t1."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+
> ")) OR
> (t0."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+
> " AND
> t3."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
>
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))+
>
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append(",")
>
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(",")
>
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append(")
> AND EXISTS(SELECT 'x' FROM ").append(jobs.getTableName()).append(" t1
> WHERE t0.")
>
> .append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_COMPLETE))).append(",")
>
> .append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_PURGATORY))).append(")")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_READYFORSTARTUP))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_STARTINGUP))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUPFORRESTART))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUP))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))).append(",")
>
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTING))).append(",")
>
> .append(database.quoteSQLSt
Re: Release?
Here is a list of the pertinent places where quoteSQLString is used.
Note that EXCEPT in a couple of cases where quoteSQLString was needed
to furnish an argument for a clause being formed by a database
abstraction method, ALL other cases are quoting of constant values,
save in one case, which I am happy to change.
>>
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/Jobs.java
getTableName()+" WHERE
"+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE))+
" AND
"+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE_NOOUTPUT))+
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")
"+constructOffsetLimitClause(0,1),null,null,null,1);
statusField+" IN
("+quoteSQLString(statusToString(STATUS_READYFORDELETE))+","+
quoteSQLString(statusToString(STATUS_SHUTTINGDOWN))+")
"+constructOffsetLimitClause(0,1),
quoteSQLString(statusToString(STATUS_ACTIVE)) + "," +
quoteSQLString(statusToString(STATUS_ACTIVESEEDING)) +
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobManager.java
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))+
" AND
t1."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+
")) OR
(t0."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+
" AND
t3."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))+
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append(")
AND EXISTS(SELECT 'x' FROM ").append(jobs.getTableName()).append(" t1
WHERE t0.")
.append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_COMPLETE))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_PURGATORY))).append(")")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_READYFORSTARTUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_STARTINGUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUPFORRESTART))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTART))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTARTSEEDING))).append("))
AND ")
.append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDING))).append(",")
.append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(")
AN
Re: Release?
quoteSQLString is used mainly for data content that is not directly sourced from input, such as state values, etc. So your concern is unlikely to be actually true. But even so, if you are saying that all of these should be converted to prepared values, fine - but this would be a large job and is likely to be error prone. Would it not be better to address any concerns you might have about quoteSQLString instead? Since quoteSQLString uses ' as it's quotation mark, and properly escapes ' characters within the string, I claim that the method is properly written and cannot be used for a sql attack. If you disagree, provide me a string that "breaks" the escaping that it does. The definition of such breakage is a string that, when escaped with quoteSQLString, causes the query to interpret ANY of the string's contents as something other than the string. The link you provided lists many kinds of exploit, most of them fundamentally issues with (a) non-escaping of strings, and (b) taking advantage of flaws in (say) PHP or ASP. ALL of them are thwarted by proper escaping of character content. Karl On Mon, Dec 6, 2010 at 7:30 PM, Robert Muir wrote: > On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright wrote: > >> As for the sql injection question, please elaborate. There is no UI >> ability to do sql injection that I am aware of, because all the >> strings you might enter are properly escaped before being incorporated >> into queries. This includes queries that come via the API and >> Authority Service. So I guess I need an example of how you might >> cause a sql injection given the current code. >> > > Escaping tends to only thwart casual attackers, not motivated ones or > even automated tools. > > For example the escaping i see used here: e.g. quoteSQLString seems to > only quote single-quote characters. > > There are a number of techniques to workaround this type of escaping, > some are listed here: > http://www.slideshare.net/inquis/sql-injection-not-only-and-11 > > In my opinion all variables should be explicitly bound via PreparedStatements. >
Re: Release?
On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright wrote: > As for the sql injection question, please elaborate. There is no UI > ability to do sql injection that I am aware of, because all the > strings you might enter are properly escaped before being incorporated > into queries. This includes queries that come via the API and > Authority Service. So I guess I need an example of how you might > cause a sql injection given the current code. > Escaping tends to only thwart casual attackers, not motivated ones or even automated tools. For example the escaping i see used here: e.g. quoteSQLString seems to only quote single-quote characters. There are a number of techniques to workaround this type of escaping, some are listed here: http://www.slideshare.net/inquis/sql-injection-not-only-and-11 In my opinion all variables should be explicitly bound via PreparedStatements.
Re: Release?
If by third-party, you mean code from Documentum, LiveLink, etc, I don't actually think we have any third-party dependencies that we ship. Remember that the compilation is all conditional, so if you want these connectors you need to drop the right things in the right places, using your own license to these materials, and then build. That's all explained in http://incubator.apache.org/connectors/how-to-build-and-deploy.html. As for the sql injection question, please elaborate. There is no UI ability to do sql injection that I am aware of, because all the strings you might enter are properly escaped before being incorporated into queries. This includes queries that come via the API and Authority Service. So I guess I need an example of how you might cause a sql injection given the current code. Karl On Mon, Dec 6, 2010 at 7:12 PM, Robert Muir wrote: > i took a quick look, i definitely agree we need to document all 3rd > party dependencies in notice.txt and include licenses with them. > > separately, i have an additional concern, and that is i'm really > concerned about a release going out with some of the database > interface code looking very prone to sql injection attacks. > > On Mon, Dec 6, 2010 at 6:45 PM, Karl Wright wrote: >> Robert has expressed a willingness to chip in on the remaining issues >> later this week, when he's no longer being buried alive. >> Thanks, Robert! >> Karl >> >> On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright wrote: >>> Ok, this too has been done. >>> Still no takers for (2) and (3). Going thrice... >>> >>> Karl >>> >>> >>> On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll wrote: Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable. -Grant On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: > Does this also apply to the top-level directory in the tar or zip as > well? or can that be left as "apache-manifoldcf-0.1"? > > Karl > > On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll > wrote: >> FYI, I think the package name needs to have the words incubating in it >> too, as in manifoldcf-0.1-incubating.tar.gz >> >> -Grant >> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: >> >>> ... going twice ... >>> >>> Karl >>> >>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: I'm done with (1), (4), and (5). Still waiting for help with (2) and (3)... going once Karl On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: > OK, so I will do the appropriate things to make (1), (4), and maybe > (5) happen. Does anyone want to help with (2), (3), and (8)? > Karl > > On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll > wrote: >> >> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: >> >>> Hi Grant, >>> >>> In offline conversation you clarified that for (1) you are looking >>> for >>> the top level dir in the zip/tar to be named >>> "apache-manifoldcf-0.1". >>> You also seem to be asking for a number of other fixes that are >>> specific to a release, that I presume would NOT be in sources on >>> trunk >>> (e.g. CHANGES.txt). Are you envisioning that we make these specific >>> changes in the release branch only? >> >> It's perfectly fine for CHANGES.txt to be on trunk. You make the >> change marking it as 0.1. Once the release is out, you add a new >> section at the top for trunk again. >> >> Later, as we mature, we will likely have branches, etc. for this >> stuff, but for now let's just assume trunk is under code freeze and >> the only changes that can be made are those related to release. >> >> >>> >>> Karl >>> >>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll >>> wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? >>
Re: Release?
i took a quick look, i definitely agree we need to document all 3rd party dependencies in notice.txt and include licenses with them. separately, i have an additional concern, and that is i'm really concerned about a release going out with some of the database interface code looking very prone to sql injection attacks. On Mon, Dec 6, 2010 at 6:45 PM, Karl Wright wrote: > Robert has expressed a willingness to chip in on the remaining issues > later this week, when he's no longer being buried alive. > Thanks, Robert! > Karl > > On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright wrote: >> Ok, this too has been done. >> Still no takers for (2) and (3). Going thrice... >> >> Karl >> >> >> On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll wrote: >>> Typically, the practice is that the name of the file is the name of the >>> directory, but I don't know that it has to be. Just easier, since you only >>> need one Ant variable. >>> >>> -Grant >>> >>> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: >>> Does this also apply to the top-level directory in the tar or zip as well? or can that be left as "apache-manifoldcf-0.1"? Karl On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll wrote: > FYI, I think the package name needs to have the words incubating in it > too, as in manifoldcf-0.1-incubating.tar.gz > > -Grant > On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: > >> ... going twice ... >> >> Karl >> >> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: >>> I'm done with (1), (4), and (5). Still waiting for help with (2) and >>> (3)... going once >>> >>> Karl >>> >>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: OK, so I will do the appropriate things to make (1), (4), and maybe (5) happen. Does anyone want to help with (2), (3), and (8)? Karl On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll wrote: > > On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: > >> Hi Grant, >> >> In offline conversation you clarified that for (1) you are looking >> for >> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". >> You also seem to be asking for a number of other fixes that are >> specific to a release, that I presume would NOT be in sources on >> trunk >> (e.g. CHANGES.txt). Are you envisioning that we make these specific >> changes in the release branch only? > > It's perfectly fine for CHANGES.txt to be on trunk. You make the > change marking it as 0.1. Once the release is out, you add a new > section at the top for trunk again. > > Later, as we mature, we will likely have branches, etc. for this > stuff, but for now let's just assume trunk is under code freeze and > the only changes that can be made are those related to release. > > >> >> Karl >> >> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll >> wrote: >>> We're close, but I think we've got a few more things to do. I did >>> get it to compile. >>> >>> Notes: >>> >>> 1. We should package the stuff all under apache-manifold-0.1 so >>> that when we unzip it's all in one folder. >>> 2. Many of the libs require an entry in the NOTICE.txt file >>> 3. All licenses for those libs need to be appended on to the end >>> of the LICENSE.txt file (See Solr's for instance) >>> 4. The CHANGES.txt file should reflect that it is a release and not >>> trunk (not critical to fix) >>> 5. Is there anyway to make the package smaller? Maybe we don't >>> need to ship both PDF and HTML for the docs. Anything else we can >>> trim? >>> 6. What's json/org/json all about? >>> 7. I still see Memex stuff in connectors dir. I didn't check other >>> places. >>> 8. We should hook in RAT (see Solr's build file) to verify that all >>> source files have appropriate license headers >>> >>> Other than that, some other eyes on it would be good. >>> >>> -Grant >>> >>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: >>> Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright wrote: > ok - I might move it there > Karl > > > On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll > wrote: >> Weird, ~kwright doesn't resolve for me on people.a.o, but I can >> get to /x1/home/kwright >> >> FWIW, if you have a public_html directory in your directory and >> then place the files there, everyone can
Re: Release?
Robert has expressed a willingness to chip in on the remaining issues later this week, when he's no longer being buried alive. Thanks, Robert! Karl On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright wrote: > Ok, this too has been done. > Still no takers for (2) and (3). Going thrice... > > Karl > > > On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll wrote: >> Typically, the practice is that the name of the file is the name of the >> directory, but I don't know that it has to be. Just easier, since you only >> need one Ant variable. >> >> -Grant >> >> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: >> >>> Does this also apply to the top-level directory in the tar or zip as >>> well? or can that be left as "apache-manifoldcf-0.1"? >>> >>> Karl >>> >>> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll wrote: FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz -Grant On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: > ... going twice ... > > Karl > > On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: >> I'm done with (1), (4), and (5). Still waiting for help with (2) and >> (3)... going once >> >> Karl >> >> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: >>> OK, so I will do the appropriate things to make (1), (4), and maybe >>> (5) happen. Does anyone want to help with (2), (3), and (8)? >>> Karl >>> >>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll >>> wrote: On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: > Hi Grant, > > In offline conversation you clarified that for (1) you are looking for > the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". > You also seem to be asking for a number of other fixes that are > specific to a release, that I presume would NOT be in sources on trunk > (e.g. CHANGES.txt). Are you envisioning that we make these specific > changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. > > Karl > > On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll > wrote: >> We're close, but I think we've got a few more things to do. I did >> get it to compile. >> >> Notes: >> >> 1. We should package the stuff all under apache-manifold-0.1 so that >> when we unzip it's all in one folder. >> 2. Many of the libs require an entry in the NOTICE.txt file >> 3. All licenses for those libs need to be appended on to the end of >> the LICENSE.txt file (See Solr's for instance) >> 4. The CHANGES.txt file should reflect that it is a release and not >> trunk (not critical to fix) >> 5. Is there anyway to make the package smaller? Maybe we don't need >> to ship both PDF and HTML for the docs. Anything else we can trim? >> 6. What's json/org/json all about? >> 7. I still see Memex stuff in connectors dir. I didn't check other >> places. >> 8. We should hook in RAT (see Solr's build file) to verify that all >> source files have appropriate license headers >> >> Other than that, some other eyes on it would be good. >> >> -Grant >> >> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: >> >>> Done >>> Karl >>> >>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright >>> wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll wrote: > Weird, ~kwright doesn't resolve for me on people.a.o, but I can > get to /x1/home/kwright > > FWIW, if you have a public_html directory in your directory and > then place the files there, everyone can download them and check > them out at http://people.apache.org/~kwright/ > > -Grant > > On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: > >> While I was looking for a solution, an upload attempt succeeded! >> >> So there is now an RC0 out on people.apache.org/~kwright: >> >> [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* >> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 >
Re: Release?
Ok, this too has been done. Still no takers for (2) and (3). Going thrice... Karl On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll wrote: > Typically, the practice is that the name of the file is the name of the > directory, but I don't know that it has to be. Just easier, since you only > need one Ant variable. > > -Grant > > On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: > >> Does this also apply to the top-level directory in the tar or zip as >> well? or can that be left as "apache-manifoldcf-0.1"? >> >> Karl >> >> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll wrote: >>> FYI, I think the package name needs to have the words incubating in it too, >>> as in manifoldcf-0.1-incubating.tar.gz >>> >>> -Grant >>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: >>> ... going twice ... Karl On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: > I'm done with (1), (4), and (5). Still waiting for help with (2) and > (3)... going once > > Karl > > On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: >> OK, so I will do the appropriate things to make (1), (4), and maybe >> (5) happen. Does anyone want to help with (2), (3), and (8)? >> Karl >> >> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll >> wrote: >>> >>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: >>> Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? >>> >>> It's perfectly fine for CHANGES.txt to be on trunk. You make the >>> change marking it as 0.1. Once the release is out, you add a new >>> section at the top for trunk again. >>> >>> Later, as we mature, we will likely have branches, etc. for this stuff, >>> but for now let's just assume trunk is under code freeze and the only >>> changes that can be made are those related to release. >>> >>> Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll wrote: > We're close, but I think we've got a few more things to do. I did > get it to compile. > > Notes: > > 1. We should package the stuff all under apache-manifold-0.1 so that > when we unzip it's all in one folder. > 2. Many of the libs require an entry in the NOTICE.txt file > 3. All licenses for those libs need to be appended on to the end of > the LICENSE.txt file (See Solr's for instance) > 4. The CHANGES.txt file should reflect that it is a release and not > trunk (not critical to fix) > 5. Is there anyway to make the package smaller? Maybe we don't need > to ship both PDF and HTML for the docs. Anything else we can trim? > 6. What's json/org/json all about? > 7. I still see Memex stuff in connectors dir. I didn't check other > places. > 8. We should hook in RAT (see Solr's build file) to verify that all > source files have appropriate license headers > > Other than that, some other eyes on it would be good. > > -Grant > > On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: > >> Done >> Karl >> >> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright >> wrote: >>> ok - I might move it there >>> Karl >>> >>> >>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll >>> wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: > While I was looking for a solution, an upload attempt succeeded! > > So there is now an RC0 out on people.apache.org/~kwright: > > [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* > -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 > manifoldcf-0.1.tar.gz.md5 > -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 > manifoldcf-0.1.zip.md5 > -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 > manifoldcf-0.1.zip > -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 > manifold
Re: Release?
Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable. -Grant On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: > Does this also apply to the top-level directory in the tar or zip as > well? or can that be left as "apache-manifoldcf-0.1"? > > Karl > > On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll wrote: >> FYI, I think the package name needs to have the words incubating in it too, >> as in manifoldcf-0.1-incubating.tar.gz >> >> -Grant >> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: >> >>> ... going twice ... >>> >>> Karl >>> >>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: I'm done with (1), (4), and (5). Still waiting for help with (2) and (3)... going once Karl On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: > OK, so I will do the appropriate things to make (1), (4), and maybe > (5) happen. Does anyone want to help with (2), (3), and (8)? > Karl > > On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll > wrote: >> >> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: >> >>> Hi Grant, >>> >>> In offline conversation you clarified that for (1) you are looking for >>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". >>> You also seem to be asking for a number of other fixes that are >>> specific to a release, that I presume would NOT be in sources on trunk >>> (e.g. CHANGES.txt). Are you envisioning that we make these specific >>> changes in the release branch only? >> >> It's perfectly fine for CHANGES.txt to be on trunk. You make the change >> marking it as 0.1. Once the release is out, you add a new section at >> the top for trunk again. >> >> Later, as we mature, we will likely have branches, etc. for this stuff, >> but for now let's just assume trunk is under code freeze and the only >> changes that can be made are those related to release. >> >> >>> >>> Karl >>> >>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll >>> wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? 7. I still see Memex stuff in connectors dir. I didn't check other places. 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers Other than that, some other eyes on it would be good. -Grant On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: > Done > Karl > > On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright > wrote: >> ok - I might move it there >> Karl >> >> >> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll >> wrote: >>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get >>> to /x1/home/kwright >>> >>> FWIW, if you have a public_html directory in your directory and >>> then place the files there, everyone can download them and check >>> them out at http://people.apache.org/~kwright/ >>> >>> -Grant >>> >>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: >>> While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright wrote:
Re: Release?
Does this also apply to the top-level directory in the tar or zip as well? or can that be left as "apache-manifoldcf-0.1"? Karl On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll wrote: > FYI, I think the package name needs to have the words incubating in it too, > as in manifoldcf-0.1-incubating.tar.gz > > -Grant > On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: > >> ... going twice ... >> >> Karl >> >> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: >>> I'm done with (1), (4), and (5). Still waiting for help with (2) and >>> (3)... going once >>> >>> Karl >>> >>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: OK, so I will do the appropriate things to make (1), (4), and maybe (5) happen. Does anyone want to help with (2), (3), and (8)? Karl On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll wrote: > > On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: > >> Hi Grant, >> >> In offline conversation you clarified that for (1) you are looking for >> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". >> You also seem to be asking for a number of other fixes that are >> specific to a release, that I presume would NOT be in sources on trunk >> (e.g. CHANGES.txt). Are you envisioning that we make these specific >> changes in the release branch only? > > It's perfectly fine for CHANGES.txt to be on trunk. You make the change > marking it as 0.1. Once the release is out, you add a new section at the > top for trunk again. > > Later, as we mature, we will likely have branches, etc. for this stuff, > but for now let's just assume trunk is under code freeze and the only > changes that can be made are those related to release. > > >> >> Karl >> >> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll >> wrote: >>> We're close, but I think we've got a few more things to do. I did get >>> it to compile. >>> >>> Notes: >>> >>> 1. We should package the stuff all under apache-manifold-0.1 so that >>> when we unzip it's all in one folder. >>> 2. Many of the libs require an entry in the NOTICE.txt file >>> 3. All licenses for those libs need to be appended on to the end of >>> the LICENSE.txt file (See Solr's for instance) >>> 4. The CHANGES.txt file should reflect that it is a release and not >>> trunk (not critical to fix) >>> 5. Is there anyway to make the package smaller? Maybe we don't need to >>> ship both PDF and HTML for the docs. Anything else we can trim? >>> 6. What's json/org/json all about? >>> 7. I still see Memex stuff in connectors dir. I didn't check other >>> places. >>> 8. We should hook in RAT (see Solr's build file) to verify that all >>> source files have appropriate license headers >>> >>> Other than that, some other eyes on it would be good. >>> >>> -Grant >>> >>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: >>> Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright wrote: > ok - I might move it there > Karl > > > On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll > wrote: >> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get >> to /x1/home/kwright >> >> FWIW, if you have a public_html directory in your directory and then >> place the files there, everyone can download them and check them out >> at http://people.apache.org/~kwright/ >> >> -Grant >> >> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: >> >>> While I was looking for a solution, an upload attempt succeeded! >>> >>> So there is now an RC0 out on people.apache.org/~kwright: >>> >>> [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* >>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 >>> manifoldcf-0.1.tar.gz.md5 >>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 >>> manifoldcf-0.1.zip.md5 >>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 >>> manifoldcf-0.1.zip >>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 >>> manifoldcf-0.1.tar.gz >>> [kwri...@minotaur:~]$ >>> >>> Please let me know what you think. >>> Karl >>> >>> >>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright >>> wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright wrote: > I'm uploading a release candidate now. But someone needs to feed > the > hamsters turning the wheels or something, because the up
Re: Release?
FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz -Grant On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: > ... going twice ... > > Karl > > On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: >> I'm done with (1), (4), and (5). Still waiting for help with (2) and >> (3)... going once >> >> Karl >> >> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: >>> OK, so I will do the appropriate things to make (1), (4), and maybe >>> (5) happen. Does anyone want to help with (2), (3), and (8)? >>> Karl >>> >>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll wrote: On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: > Hi Grant, > > In offline conversation you clarified that for (1) you are looking for > the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". > You also seem to be asking for a number of other fixes that are > specific to a release, that I presume would NOT be in sources on trunk > (e.g. CHANGES.txt). Are you envisioning that we make these specific > changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. > > Karl > > On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll > wrote: >> We're close, but I think we've got a few more things to do. I did get >> it to compile. >> >> Notes: >> >> 1. We should package the stuff all under apache-manifold-0.1 so that >> when we unzip it's all in one folder. >> 2. Many of the libs require an entry in the NOTICE.txt file >> 3. All licenses for those libs need to be appended on to the end of the >> LICENSE.txt file (See Solr's for instance) >> 4. The CHANGES.txt file should reflect that it is a release and not >> trunk (not critical to fix) >> 5. Is there anyway to make the package smaller? Maybe we don't need to >> ship both PDF and HTML for the docs. Anything else we can trim? >> 6. What's json/org/json all about? >> 7. I still see Memex stuff in connectors dir. I didn't check other >> places. >> 8. We should hook in RAT (see Solr's build file) to verify that all >> source files have appropriate license headers >> >> Other than that, some other eyes on it would be good. >> >> -Grant >> >> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: >> >>> Done >>> Karl >>> >>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll wrote: > Weird, ~kwright doesn't resolve for me on people.a.o, but I can get > to /x1/home/kwright > > FWIW, if you have a public_html directory in your directory and then > place the files there, everyone can download them and check them out > at http://people.apache.org/~kwright/ > > -Grant > > On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: > >> While I was looking for a solution, an upload attempt succeeded! >> >> So there is now an RC0 out on people.apache.org/~kwright: >> >> [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* >> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 >> manifoldcf-0.1.tar.gz.md5 >> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 >> manifoldcf-0.1.zip.md5 >> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 >> manifoldcf-0.1.zip >> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 >> manifoldcf-0.1.tar.gz >> [kwri...@minotaur:~]$ >> >> Please let me know what you think. >> Karl >> >> >> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright >> wrote: >>> The upload has failed repeatedly for me, so I'll clearly have to >>> find >>> another way. >>> Karl >>> >>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright >>> wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl >>>
Re: Release?
... going twice ... Karl On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright wrote: > I'm done with (1), (4), and (5). Still waiting for help with (2) and > (3)... going once > > Karl > > On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright wrote: >> OK, so I will do the appropriate things to make (1), (4), and maybe >> (5) happen. Does anyone want to help with (2), (3), and (8)? >> Karl >> >> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll wrote: >>> >>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: >>> Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named "apache-manifoldcf-0.1". You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? >>> >>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change >>> marking it as 0.1. Once the release is out, you add a new section at the >>> top for trunk again. >>> >>> Later, as we mature, we will likely have branches, etc. for this stuff, but >>> for now let's just assume trunk is under code freeze and the only changes >>> that can be made are those related to release. >>> >>> Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll wrote: > We're close, but I think we've got a few more things to do. I did get it > to compile. > > Notes: > > 1. We should package the stuff all under apache-manifold-0.1 so that when > we unzip it's all in one folder. > 2. Many of the libs require an entry in the NOTICE.txt file > 3. All licenses for those libs need to be appended on to the end of the > LICENSE.txt file (See Solr's for instance) > 4. The CHANGES.txt file should reflect that it is a release and not trunk > (not critical to fix) > 5. Is there anyway to make the package smaller? Maybe we don't need to > ship both PDF and HTML for the docs. Anything else we can trim? > 6. What's json/org/json all about? > 7. I still see Memex stuff in connectors dir. I didn't check other > places. > 8. We should hook in RAT (see Solr's build file) to verify that all > source files have appropriate license headers > > Other than that, some other eyes on it would be good. > > -Grant > > On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: > >> Done >> Karl >> >> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright wrote: >>> ok - I might move it there >>> Karl >>> >>> >>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll >>> wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: > While I was looking for a solution, an upload attempt succeeded! > > So there is now an RC0 out on people.apache.org/~kwright: > > [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* > -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 > manifoldcf-0.1.tar.gz.md5 > -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 > manifoldcf-0.1.zip.md5 > -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 > manifoldcf-0.1.zip > -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 > manifoldcf-0.1.tar.gz > [kwri...@minotaur:~]$ > > Please let me know what you think. > Karl > > > On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright > wrote: >> The upload has failed repeatedly for me, so I'll clearly have to find >> another way. >> Karl >> >> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright >> wrote: >>> I'm uploading a release candidate now. But someone needs to feed >>> the >>> hamsters turning the wheels or something, because the upload speed >>> to >>> that machine is 51KB/sec, so it's going to take 3 hours to get the >>> candidate up there, if my network connection doesn't bounce in the >>> interim. Is there any other place available? >>> >>> Karl >>> >>> On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll >>> wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: > I've created a signing key, and checked in a KEYS file. Apache > instructions for this are actually decent, so I didn't have to > make >>
