t/ssl/ocsp.t
Hi, I see test errors in #1 and #3 in t/ssl/ocsp.t. Does anyone else see it? Looking deeper at the output (i.e. --verbose), it looks like the issue is in the test itself. All conditions seem to be there, but I need to turn: my $message = $r->message(); into: my $message = $r->content(); in both tests to have them pass. Is it expected? I don't remind issues with this test in the past. This part of the test has been changed in r1844479. CJ
Re: [VOTE] Release httpd-2.4.38
On Thu, Jan 17, 2019 at 7:49 PM Daniel Ruggeri wrote: > > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ http://httpd.apache.org/dev/dist/
[VOTE] Release httpd-2.4.38
Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.38: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz sha256: 38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6 *httpd-2.4.38.tar.gz -- Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.28
Thank you, folks. I apologize again for the embarrassing mistake. Will be sending along the updated vote email in a few seconds. -- Daniel Ruggeri On 2019-01-17 12:30, Yann Ylavic wrote: We should at the same 2.4.x state as before the release try now, I think the script(s) can be restarted with the correct tag/version (2.4.38! ;) ) as if it were the first time. On Thu, Jan 17, 2019 at 7:05 PM William A Rowe Jr wrote: An aside r.e. subversion; Just please don't do what gstein has warned us against. I've performed the ill-advised jump-over abandoned work in the past; svn rm ^/httpd/mod_foo/trunk svn cp ^/httpd/mod_foo/trunk@123456 ^/httpd/mod_foo/trunk attempting to drop activity between 123457 and present. Greg advised us this turns out to do some ugly rebasing leaving a very ugly mess of records in the underlying database. Anyone from subversion team could give a better explanation why this is badness. This might look like a reversion, but don't do this. On Thu, Jan 17, 2019 at 12:00 PM Daniel Gruno wrote: It's subversion, not git - we can always revert ;p
Re: [VOTE] Release httpd-2.4.28
We should at the same 2.4.x state as before the release try now, I think the script(s) can be restarted with the correct tag/version (2.4.38! ;) ) as if it were the first time. On Thu, Jan 17, 2019 at 7:05 PM William A Rowe Jr wrote: > > An aside r.e. subversion; > > Just please don't do what gstein has warned us against. I've performed > the ill-advised jump-over abandoned work in the past; >svn rm ^/httpd/mod_foo/trunk >svn cp ^/httpd/mod_foo/trunk@123456 ^/httpd/mod_foo/trunk > attempting to drop activity between 123457 and present. Greg advised > us this turns out to do some ugly rebasing leaving a very ugly mess of > records in the underlying database. Anyone from subversion team could > give a better explanation why this is badness. This might look like > a reversion, but don't do this. > > On Thu, Jan 17, 2019 at 12:00 PM Daniel Gruno wrote: >> >> >> It's subversion, not git - we can always revert ;p > >
Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h
On Thu, Jan 17, 2019 at 12:07 PM William A Rowe Jr wrote: > On Thu, Jan 17, 2019 at 12:03 PM Daniel Ruggeri > wrote: > >> >> We had a commit after the tag, > > > There are no tags. They are figments of your imagination :) When we > publish a tarball (even just under /dev/dist/), then we have a tag. > > Please svn rm the errant 2.4.39 tag. > (erm... svn rm the 2.4.38 tag I mean, please avoid modifying the files beneath /tags/.) > so I've updated only the STATUS/CHANGES >> files to correct the errant lines. I also svn rm'ed the extra tree under >> the 2.4.28 tag. >> > > What about fixing ap_release.h please? >
Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h
On Thu, Jan 17, 2019 at 12:03 PM Daniel Ruggeri wrote: > > We had a commit after the tag, There are no tags. They are figments of your imagination :) When we publish a tarball (even just under /dev/dist/), then we have a tag. Please svn rm the errant 2.4.39 tag. so I've updated only the STATUS/CHANGES > files to correct the errant lines. I also svn rm'ed the extra tree under > the 2.4.28 tag. > What about fixing ap_release.h please?
Re: [VOTE] Release httpd-2.4.28
An aside r.e. subversion; Just please don't do what gstein has warned us against. I've performed the ill-advised jump-over abandoned work in the past; svn rm ^/httpd/mod_foo/trunk svn cp ^/httpd/mod_foo/trunk@123456 ^/httpd/mod_foo/trunk attempting to drop activity between 123457 and present. Greg advised us this turns out to do some ugly rebasing leaving a very ugly mess of records in the underlying database. Anyone from subversion team could give a better explanation why this is badness. This might look like a reversion, but don't do this. On Thu, Jan 17, 2019 at 12:00 PM Daniel Gruno wrote: > > It's subversion, not git - we can always revert ;p >
Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h
Yes indeed - too true! I'll be adding a failsafe for this in the scripts so it won't happen again. We had a commit after the tag, so I've updated only the STATUS/CHANGES files to correct the errant lines. I also svn rm'ed the extra tree under the 2.4.28 tag. I'll redo in about 30 more minutes - with the right version number fed to the machine. -- Daniel Ruggeri On 2019-01-17 11:51, William A Rowe Jr wrote: One problem with scripts, they do just what they are told. You just tagged 2.4.39 as 2.4.38. Please revert to 2.4.38 and tag - until the tarballs are published to vote on, it's all development in svn history. On Thu, Jan 17, 2019 at 11:48 AM wrote: Author: druggeri Date: Thu Jan 17 17:48:40 2019 New Revision: 1851557 URL: http://svn.apache.org/viewvc?rev=1851557&view=rev [1] Log: Get ready to tag httpd 2.4.38 Modified: httpd/httpd/branches/2.4.x/include/ap_release.h Modified: httpd/httpd/branches/2.4.x/include/ap_release.h URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557&r1=1851556&r2=1851557&view=diff [2] == --- httpd/httpd/branches/2.4.x/include/ap_release.h (original) +++ httpd/httpd/branches/2.4.x/include/ap_release.h Thu Jan 17 17:48:40 2019 @@ -44,7 +44,7 @@ #define AP_SERVER_MAJORVERSION_NUMBER 2 #define AP_SERVER_MINORVERSION_NUMBER 4 #define AP_SERVER_PATCHLEVEL_NUMBER 39 -#define AP_SERVER_DEVBUILD_BOOLEAN 1 +#define AP_SERVER_DEVBUILD_BOOLEAN 0 /* Synchronize the above with docs/manual/style/version.ent */ Links: -- [1] http://svn.apache.org/viewvc?rev=1851557&view=rev [2] http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557&r1=1851556&r2=1851557&view=diff
Re: [VOTE] Release httpd-2.4.28
On 1/17/19 6:59 PM, Jim Jagielski wrote: Ahhh good. On Jan 17, 2019, at 12:46 PM, Yann Ylavic wrote: On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski wrote: Note that simply changing the commit msg logs does not solve the problem. There is, in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 2.4.28 tag... :( Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed already. It's subversion, not git - we can always revert ;p
Re: [VOTE] Release httpd-2.4.28
Ahhh good. > On Jan 17, 2019, at 12:46 PM, Yann Ylavic wrote: > > On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski wrote: >> >> Note that simply changing the commit msg logs does not solve the problem. >> There is, >> in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" >> 2.4.28 tag... :( > > Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed > already.
Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h
One problem with scripts, they do just what they are told. You just tagged 2.4.39 as 2.4.38. Please revert to 2.4.38 and tag - until the tarballs are published to vote on, it's all development in svn history. On Thu, Jan 17, 2019 at 11:48 AM wrote: > Author: druggeri > Date: Thu Jan 17 17:48:40 2019 > New Revision: 1851557 > > URL: http://svn.apache.org/viewvc?rev=1851557&view=rev > Log: > Get ready to tag httpd 2.4.38 > > Modified: > httpd/httpd/branches/2.4.x/include/ap_release.h > > Modified: httpd/httpd/branches/2.4.x/include/ap_release.h > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557&r1=1851556&r2=1851557&view=diff > > == > --- httpd/httpd/branches/2.4.x/include/ap_release.h (original) > +++ httpd/httpd/branches/2.4.x/include/ap_release.h Thu Jan 17 17:48:40 > 2019 > @@ -44,7 +44,7 @@ > #define AP_SERVER_MAJORVERSION_NUMBER 2 > #define AP_SERVER_MINORVERSION_NUMBER 4 > #define AP_SERVER_PATCHLEVEL_NUMBER 39 > -#define AP_SERVER_DEVBUILD_BOOLEAN1 > +#define AP_SERVER_DEVBUILD_BOOLEAN0 > > /* Synchronize the above with docs/manual/style/version.ent */ > > > >
Re: [VOTE] Release httpd-2.4.28
On Thu, Jan 17, 2019 at 11:44 AM Jim Jagielski wrote: > Note that simply changing the commit msg logs does not solve the problem. > There is, > in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" > 2.4.28 tag... :( Not destroyed, as ylavic observed. Nothing gets destroyed in revision control without a ton of extra effort (at least not in subversion... git is another story.)
Re: [VOTE] Release httpd-2.4.28
On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski wrote: > > Note that simply changing the commit msg logs does not solve the problem. > There is, > in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" > 2.4.28 tag... :( Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed already.
Re: svn propchange: r1851549 - svn:log
Ahhh, true. Adjusted message appropriately. On Thu, Jan 17, 2019 at 11:44 AM Yann Ylavic wrote: > On Thu, Jan 17, 2019 at 6:36 PM wrote: > > > > Author: wrowe > > Revision: 1851549 > > Modified property: svn:log > > > > Modified: svn:log at Thu Jan 17 17:36:04 2019 > > > -- > > --- svn:log (original) > > +++ svn:log Thu Jan 17 17:36:04 2019 > > @@ -1 +1,3 @@ > > -Tag HEAD of 2.4.x as 2.4.28 > > +Tag HEAD of 2.4.x as 2.4.38 > > + > > +[Corrected commit message] > > No it's not AFAICT, the tag existed already so it all ended up as a > subdirectory of tags/2.4.28 (see below). > > Added: > httpd/httpd/tags/2.4.28/2.4.x/ (props changed) > - copied from r1851548, httpd/httpd/branches/2.4.x/ > > Propchange: httpd/httpd/tags/2.4.28/2.4.x/ >
Re: [VOTE] Release httpd-2.4.28
Note that simply changing the commit msg logs does not solve the problem. There is, in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 2.4.28 tag... :(
Re: svn propchange: r1851549 - svn:log
On Thu, Jan 17, 2019 at 6:36 PM wrote: > > Author: wrowe > Revision: 1851549 > Modified property: svn:log > > Modified: svn:log at Thu Jan 17 17:36:04 2019 > -- > --- svn:log (original) > +++ svn:log Thu Jan 17 17:36:04 2019 > @@ -1 +1,3 @@ > -Tag HEAD of 2.4.x as 2.4.28 > +Tag HEAD of 2.4.x as 2.4.38 > + > +[Corrected commit message] No it's not AFAICT, the tag existed already so it all ended up as a subdirectory of tags/2.4.28 (see below). Added: httpd/httpd/tags/2.4.28/2.4.x/ (props changed) - copied from r1851548, httpd/httpd/branches/2.4.x/ Propchange: httpd/httpd/tags/2.4.28/2.4.x/
Re: [VOTE] Release httpd-2.4.28
See no tarball at https://dist.apache.org/repos/dist/dev/httpd/ Also in SVN and Subject of theis mauk I see 2.4.28 instead of 2.4.28 On 17-01-19 18:13, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.28: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz
Re: [VOTE] Release httpd-2.4.28
Sorry make the same mistake :) See no tarball at https://dist.apache.org/repos/dist/dev/httpd/ I was used to see the URL http://httpd.apache.org/dev/dist/ also there no tarball Also in SVN and Subject of this mail I see 2.4.28 instead of 2.4.38 On 17-01-19 18:24, Jim Jagielski wrote: Shouldn't this be 2.4.38?? On Jan 17, 2019, at 12:13 PM, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.28: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz -- Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.28
On 2019-01-17 11:24, Jim Jagielski wrote: Shouldn't this be 2.4.38?? On Jan 17, 2019, at 12:13 PM, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.28: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz -- Daniel Ruggeri Ahh! Another typo! Please disregard this thread - will redo with the correct version. -- Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.28
Shouldn't this be 2.4.38?? > On Jan 17, 2019, at 12:13 PM, Daniel Ruggeri wrote: > > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this candidate > tarball as 2.4.28: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz > sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 > *httpd-2.4.28.tar.gz > > -- > Daniel Ruggeri
Re: svn commit: r1851549 - /httpd/httpd/tags/2.4.28/2.4.x/
2.4.28? > On Jan 17, 2019, at 12:08 PM, drugg...@apache.org wrote: > > Author: druggeri > Date: Thu Jan 17 17:08:22 2019 > New Revision: 1851549 > > URL: http://svn.apache.org/viewvc?rev=1851549&view=rev > Log: > Tag HEAD of 2.4.x as 2.4.28 > > Added: >httpd/httpd/tags/2.4.28/2.4.x/ (props changed) > - copied from r1851548, httpd/httpd/branches/2.4.x/ > > Propchange: httpd/httpd/tags/2.4.28/2.4.x/ > -- > --- svn:ignore (added) > +++ svn:ignore Thu Jan 17 17:08:22 2019 > @@ -0,0 +1,45 @@ > +config.nice > +configure > +missing > +install-sh > +mkinstalldirs > +aclocal.m4 > +.deps > +generated_lists > +buildmk.stamp > +config.log > +Makefile > +libtool > +shlibtool > +config.status > +modules.c > +config.cache > +.libs > +httpd > +httpd.exe > +modules.lo > +Debug > +Release > +LibD > +LibR > +Apache.suo > +Apache.ncb > +Apache.opt > +apachecore.dll > +*.x > +*.aps > +*.plg > +*.dep > +*.mak > +*.rc > +Apache.sln > +BuildLog.htm > +*.stc > +*.stt > +*.sto > +*.vcproj > +*.vcproj.* > +autom4te.cache > +httpd.spec > +tags > +TAGS > > Propchange: httpd/httpd/tags/2.4.28/2.4.x/ > -- > --- svn:mergeinfo (added) > +++ svn:mergeinfo Thu Jan 17 17:08:22 2019 > @@ -0,0 +1,11 @@ > +/httpd/httpd/branches/2.4.17-protocols-changes:1712542-1715252 > +/httpd/httpd/branches/2.4.17-protocols-http2:1701609-1705681 > +/httpd/httpd/branches/2.4.x-mod_md:1816423-1821089 > +/httpd/httpd/branches/2.4.x-mpm_fdqueue:1824383-1824864 > +/httpd/httpd/branches/revert-ap-ldap:1150158-1150173 > +/httpd/httpd/branches/tlsv1.3-for-2.4.x:1840105-1841571 > +/httpd/httpd/branches/trunk-buildconf-noapr:1780253-1795930 > +/httpd/httpd/branches/trunk-md:1804087-1804529 > +/httpd/httpd/branches/trunk-override-index:1793921-1793931 > +/httpd/httpd/branches/wombat-integration:723609-723841 > +/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12 > 15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167 > ,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341905-1341906,1341913,1341930,1342065,1343085,1343087,1343094,1343099,1343109,1343935,1344712,1345147,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,1363035,1363183,1363186,1363312,1363440,1363557,1363589,1363829,1363832,1363836-1363837,1363853,1364133,1364138,1364229,1364601,1364695,1365001,1365020,1365029,1365479,1366319,1366344,1366621,1367778,1367819,1368053,1368058,1368094,1368121,1368131,1368393,1368396,1369419,1369568,1369 > 604,1369618,1369904,1369995,136,1370001,1370466,
Re: svn commit: r1850835 - /httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c
On Thu, Jan 17, 2019 at 4:03 AM Joe Orton wrote:
> On Wed, Jan 16, 2019 at 12:02:01PM -0600, William A Rowe Jr wrote:
> > Doesn't this simply gloss over an underlying defect?
> >
> > [...]
> > if (apr_dbm_fetch(f, key, &val) == APR_SUCCESS && val.dptr) {
> > *value = apr_pstrmemdup(pool, val.dptr, val.dsize);
> > }
> >
> > apr_dbm_close(f);
> >
> > return rv;
> > }
> >
> > Shouldn't we capture and return the failure code from apr_dbm_fetch here?
>
> The error code from the failed lookup is not an interesting result, I
> assume because it can only fail one way. That the lookup failed is
> reflected by returning with success *value set to NULL.
>
> I had this change in my wc from looking at clang/coverity static
> analysis results so I assume it was flagged up somewhere but can't
> remember exactly. It seems like a harmless change.
>
Thanks for the reminder, yes... most providers will return only found
or not found; not found is not an error. However some providers may
fault, e.g. DB corrupt or storage interrupted or some other very rare
edge case. APR provided to return this info, whether the underlying
provider does is another question.
I'm concerned if clang/coverity flagged the existing code, since that
suggests some edge case that may not optimize correctly.
I withdraw my objection if we layer on the following comment to
avoid future confusion/research;
/* NOT FOUND is not an error case; this is indicated by NULL result.
* Treat all NULL lookup/error results as success for the simple case
* of auth credential lookup, these are DECLINED in both cases.
*/
Does that sound like a resolution Joe?
[VOTE] Release httpd-2.4.28
Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.28: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz -- Daniel Ruggeri
Re: svn commit: r1850835 - /httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c
On Wed, Jan 16, 2019 at 12:02:01PM -0600, William A Rowe Jr wrote:
> Doesn't this simply gloss over an underlying defect?
>
> [...]
> if (apr_dbm_fetch(f, key, &val) == APR_SUCCESS && val.dptr) {
> *value = apr_pstrmemdup(pool, val.dptr, val.dsize);
> }
>
> apr_dbm_close(f);
>
> return rv;
> }
>
> Shouldn't we capture and return the failure code from apr_dbm_fetch here?
The error code from the failed lookup is not an interesting result, I
assume because it can only fail one way. That the lookup failed is
reflected by returning with success *value set to NULL.
I had this change in my wc from looking at clang/coverity static
analysis results so I assume it was flagged up somewhere but can't
remember exactly. It seems like a harmless change.
