<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Dunno what the cause might be. I think only Derek can see the output. He’s traveling this week so he probably won't be able to look at it for a few more days.<div><br></div><div>As a work around I added a Doxygen build to our CI. Like Coverage it runs on pushes but not PRs, and uploads the results to <a href="https://gnucash.github.io/gnucash/Documentation/">https://gnucash.github.io/gnucash/Documentation/</a>. If the problem really is that code needs an upgraded Doxygen then he can just redirect to there.</div><div><br></div><div>Interesting change: The GnuCash version in the heading on the old build included the full “describe” output while the new one just has the latest tag.</div><div><br></div><div>Regards,</div><div>John Ralls</div><div> <br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Jul 15, 2026, at 09:09, Geert Janssens <geert.gnucash@kobaltwit.be> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><div style="margin: 0px;">I had to go refresh my memory on that one. I didn't bump the doxygen version itself really, I merely imported a more recent doxygen.cfg file. That config file happened to come from doxygen version 1.9.7. It sets a few new variables, but I think I left all new parameters as default.</div>
<br><div style="margin: 0px;">I believe I had checked repology for the oldest distros we still supported and that lead me to doxygen 1.9.7.</div>
<br><div style="margin: 0px;">I admit I didn't think about what was installed at code to build the nightly doxygen documentation.</div>
<br><div style="margin: 0px;">But honestly, not much has changed as far as I can tell.</div>
<br><div style="margin: 0px;">I did a test with the current doxygen on my system and added a non-existent variable to doxygen.cfg. With that doxygen spits out a warning about an unknown configuration parameter but otherwise happily continues to generate the documentation.</div>
<br><div style="margin: 0px;">So I wonder if the actual issue could be that the two files used by doxygen (doxygen.cfg and <span style="font-family:monospace;"><span style=""><span style="background-color:#ffffff;">doxygen_main_page.c) have moved from the docs directory to the top-level directory and Derek's build scripts still look for them in the docs directory ?</span></span></span></div>
<br><div style="margin: 0px;">Geert</div>
<br><div style="margin: 0px;">Op maandag 13 juli 2026 18:36:50 Midden-Europese zomertijd schreef John Ralls:</div><div style="margin: 0px;">> Indeed it is. But IIRC upgrading code is a major undertaking that Derek</div><div style="margin: 0px;">> doesn’t have time for.</div><div style="margin: 0px;">> </div><div style="margin: 0px;">> Do you remember offhand what feature if any you used in that change that</div><div style="margin: 0px;">> prompted raising the Doxygen version?</div><div style="margin: 0px;">> </div><div style="margin: 0px;">> Regards,</div><div style="margin: 0px;">> John Ralls</div><div style="margin: 0px;">> </div><div style="margin: 0px;">> > On Jul 13, 2026, at 07:58, Geert Janssens <geert.gnucash@kobaltwit.be></div><div style="margin: 0px;">> > wrote:</div><div style="margin: 0px;">> > </div><div style="margin: 0px;">> > Fedora 29 is quite old by now...</div><div style="margin: 0px;">> > </div><div style="margin: 0px;">> > Op maandag 13 juli 2026 02:28:16 Midden-Europese zomertijd schreef Derek Atkins:</div><div style="margin: 0px;">> > > Maybe that was the issue.</div><div style="margin: 0px;">> > > </div><div style="margin: 0px;">> > > [root@code ~]# rpm -q doxygen</div><div style="margin: 0px;">> > > doxygen-1.8.14-7.fc29.x86_64</div><div style="margin: 0px;">> > > </div><div style="margin: 0px;">> > > -derek</div><div style="margin: 0px;">> > > </div><div style="margin: 0px;">> > > On Sun, July 12, 2026 2:10 pm, John Ralls wrote:</div><div style="margin: 0px;">> > > > Derek,</div><div style="margin: 0px;">> > > > </div><div style="margin: 0px;">> > > > That doesn’t square with the last build being two years ago, we</div><div style="margin: 0px;">> > > > removed</div><div style="margin: 0px;">> > > > auto tools in 2017. https://github.com/Gnucash/gnucash/pull/1943,</div><div style="margin: 0px;">> > > > which</div><div style="margin: 0px;">> > > > was merged immediately after the last successful docs build is the</div><div style="margin: 0px;">> > > > culprit. What version of Doxygen are you running?</div><div style="margin: 0px;">> > > > https://github.com/Gnucash/gnucash/pull/1943/changes/891b921c811f32e21</div><div style="margin: 0px;">> > > > 4fe9</div><div style="margin: 0px;">> > > > fc1a87e392b58ed7757 bumped the Doxyfile version from 1.8.3 to 1.9.7.</div><div style="margin: 0px;">> > > > </div><div style="margin: 0px;">> > > > Regards,</div><div style="margin: 0px;">> > > > John Ralls</div><div style="margin: 0px;">> > > > </div><div style="margin: 0px;">> > > >> On Jul 11, 2026, at 18:08, Derek Atkins <derek@ihtfp.com> wrote:</div><div style="margin: 0px;">> > > >> </div><div style="margin: 0px;">> > > >> Yes, doxygen not building is a known issue. The build requirements</div><div style="margin: 0px;">> > > >> changed and I've never spent the time to figure out how to update the</div><div style="margin: 0px;">> > > >> script to meet the new requirements. Specifically I used to be able</div><div style="margin: 0px;">> > > >> to</div><div style="margin: 0px;">> > > >> build the doxygen.cfg manually by calling the Makefile.am with the</div><div style="margin: 0px;">> > > >> right</div><div style="margin: 0px;">> > > >> rule. But that was removed for CMake, and I think to get that to</div><div style="margin: 0px;">> > > >> work I</div><div style="margin: 0px;">> > > >> might need to install a complete build system, which I kinda don't</div><div style="margin: 0px;">> > > >> want</div><div style="margin: 0px;">> > > >> to do. Worst case I'll have to make VM just for that.. But it just</div><div style="margin: 0px;">> > > >> hasn't been high on my priority list.</div><div style="margin: 0px;">> > > >> -derek</div><div style="margin: 0px;">> > > >> Sent using my mobile device. Please excuse any typos.</div><div style="margin: 0px;">> > > >> </div><div style="margin: 0px;">> > > >> On July 11, 2026 16:18:15 John Ralls <jralls@ceridwen.us> wrote:</div><div style="margin: 0px;">> > > >>> Noah,</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> Please always copy one of the mailing lists when you email one of</div><div style="margin: 0px;">> > > >>> the</div><div style="margin: 0px;">> > > >>> GnuCash developers unless it’s to send something like a GnuCash</div><div style="margin: 0px;">> > > >>> book;</div><div style="margin: 0px;">> > > >>> in that case the email should just have the file, all of the</div><div style="margin: 0px;">> > > >>> discussion</div><div style="margin: 0px;">> > > >>> around it should be copied to the list.</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> I’ve passed on to Derek via IRC the Doxygen-docs problem just in</div><div style="margin: 0px;">> > > >>> case</div><div style="margin: 0px;">> > > >>> he misses it here.</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> Yup, readonly-mode is largely cosmetic and applied only to the GUI.</div><div style="margin: 0px;">> > > >>> GnuCash is not designed for use by more than one user at a time and</div><div style="margin: 0px;">> > > >>> read-only mode is very simplistic.</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> I don’t think it would be too hard to extend its force to the</div><div style="margin: 0px;">> > > >>> backend</div><div style="margin: 0px;">> > > >>> so that a read-only session is blocked from writing. But if you want</div><div style="margin: 0px;">> > > >>> a</div><div style="margin: 0px;">> > > >>> read-only session to lock the database then it’s not really</div><div style="margin: 0px;">> > > >>> read-only</div><div style="margin: 0px;">> > > >>> anymore.</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> How about leveraging the database’s locking? Wrap all of the queries</div><div style="margin: 0px;">> > > >>> with dbi_conn_transaction_begin and dbi_conn_transaction_commit.</div><div style="margin: 0px;">> > > >>> That</div><div style="margin: 0px;">> > > >>> will make multi-table writes atomic with an exclusive lock, blocking</div><div style="margin: 0px;">> > > >>> a</div><div style="margin: 0px;">> > > >>> reader from reading them until the whole write is complete, while a</div><div style="margin: 0px;">> > > >>> read query while loading will block the exclusive write lock until</div><div style="margin: 0px;">> > > >>> the</div><div style="margin: 0px;">> > > >>> read is complete.</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> Regards,</div><div style="margin: 0px;">> > > >>> John Ralls</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>>> On Jul 11, 2026, at 12:24 PM, array_hourly_0u@icloud.com wrote:</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Thanks for merging #2264 and #2266 John.</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Arrg. As I've started to poke more into this read-only and lock</div><div style="margin: 0px;">> > > >>>> topic, I've found some surprises and ultimately a correctness</div><div style="margin: 0px;">> > > >>>> matter.</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> What SESSION_READ_ONLY actually means</div><div style="margin: 0px;">> > > >>>> ------------------------------------------------------------</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> 1. At the engine level, SESSION_READ_ONLY doesn't actually enforce</div><div style="margin: 0px;">> > > >>>> read-only. The mode only affects lock handling -- it does not mark</div><div style="margin: 0px;">> > > >>>> the</div><div style="margin: 0px;">> > > >>>> book read-only. Book write-protection is applied separately by the</div><div style="margin: 0px;">> > > >>>> GUI</div><div style="margin: 0px;">> > > >>>> only, which calls qof_book_mark_readonly() after opening. I</div><div style="margin: 0px;">> > > >>>> confirmed</div><div style="margin: 0px;">> > > >>>> with an API bindings test that a SESSION_READ_ONLY session can</div><div style="margin: 0px;">> > > >>>> still</div><div style="margin: 0px;">> > > >>>> edit an account and have the change persisted to the SQL store. So</div><div style="margin: 0px;">> > > >>>> an</div><div style="margin: 0px;">> > > >>>> API/bindings consumer that opens SESSION_READ_ONLY expecting the</div><div style="margin: 0px;">> > > >>>> book</div><div style="margin: 0px;">> > > >>>> to be unwritable does not get that guarantee unless it also calls</div><div style="margin: 0px;">> > > >>>> qof_book_mark_readonly() itself. [a bug if one interprets</div><div style="margin: 0px;">> > > >>>> SESSION_READ_ONLY reading the enum name while not carefully parsing</div><div style="margin: 0px;">> > > >>>> the header comments ]</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> 2. SESSION_READ_ONLY ignores the lock. A read-only consumer opens</div><div style="margin: 0px;">> > > >>>> a</div><div style="margin: 0px;">> > > >>>> book even while another process holds it open, perhaps mid-write,</div><div style="margin: 0px;">> > > >>>> which is exactly when the state can be inconsistent; and because</div><div style="margin: 0px;">> > > >>>> the</div><div style="margin: 0px;">> > > >>>> SQL backend commits incrementally, a reader can catch a</div><div style="margin: 0px;">> > > >>>> partially-applied edit. [ a read-only client correctness bug ]</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> So today the mode neither protects read consistency (it ignores the</div><div style="margin: 0px;">> > > >>>> lock) nor guarantees read-only-ness (that's a GUI add-on), even</div><div style="margin: 0px;">> > > >>>> though</div><div style="margin: 0px;">> > > >>>> the name implies both.</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Proposed path forward</div><div style="margin: 0px;">> > > >>>> -----------------------------------</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> For building read-only tools on the API, what I'd want is a</div><div style="margin: 0px;">> > > >>>> read-only</div><div style="margin: 0px;">> > > >>>> session mode that (a) takes the lock, so a writer cannot be active</div><div style="margin: 0px;">> > > >>>> while the tool reads, and (b) actually enforces no writes.</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> A possible direction would be to replace SESSION_READ_ONLY with two</div><div style="margin: 0px;">> > > >>>> modes whose names state what they do, and have both mark the book</div><div style="margin: 0px;">> > > >>>> read-only so enforcement is intrinsic rather than GUI-only:</div><div style="margin: 0px;">> > > >>>> - SESSION_READ_ONLY_EXCLUSIVE -- takes the lock (fails if the book</div><div style="margin: 0px;">> > > >>>> is</div><div style="margin: 0px;">> > > >>>> already locked); for tools that need a consistent, uninterrupted</div><div style="margin: 0px;">> > > >>>> read.</div><div style="margin: 0px;">> > > >>>> Calls qof_book_mark_readonly(). Obviously a SQL backend user would</div><div style="margin: 0px;">> > > >>>> need sufficient permissions to take the lock. I'd want to add some</div><div style="margin: 0px;">> > > >>>> user guide documentation about this where none exists today.</div><div style="margin: 0px;">> > > >>>> - SESSION_READ_ONLY_IGNORE_LOCK -- opens regardless of the lock</div><div style="margin: 0px;">> > > >>>> state;</div><div style="margin: 0px;">> > > >>>> the path the GUI's "open read-only anyway" override would use.</div><div style="margin: 0px;">> > > >>>> (i.e.</div><div style="margin: 0px;">> > > >>>> today's SESSION_READ_ONLY behavior, but with</div><div style="margin: 0px;">> > > >>>> qof_book_mark_readonly()</div><div style="margin: 0px;">> > > >>>> )</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> These could be added now, with SESSION_READ_ONLY marked deprecated,</div><div style="margin: 0px;">> > > >>>> and SESSION_READ_ONLY removed in a later release (v6? whatever that</div><div style="margin: 0px;">> > > >>>> timeframe turns out to be). I believe the deprecation warning</div><div style="margin: 0px;">> > > >>>> would</div><div style="margin: 0px;">> > > >>>> only apply to users of the API `SESSION_READ_ONLY` mode today. (The</div><div style="margin: 0px;">> > > >>>> GUI internal use would be swapped to</div><div style="margin: 0px;">> > > >>>> SESSION_READ_ONLY_IGNORE_LOCK.)"</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Does folding read-only enforcement into the mode (so bindings</div><div style="margin: 0px;">> > > >>>> consumers get it too), plus splitting the lock behavior, sound like</div><div style="margin: 0px;">> > > >>>> an</div><div style="margin: 0px;">> > > >>>> OK path?</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Aside, is it a known issue Doxygen isn't updating / is stale?</div><div style="margin: 0px;">> > > >>>> (title</div><div style="margin: 0px;">> > > >>>> says "GnuCash 5.6-150-g038405b370+" )</div><div style="margin: 0px;">> > > >>>> https://code.gnucash.org/docs/STABLE/qofsession_8h.html</div><div style="margin: 0px;">> > > >>>> I was initially looking for the enum descriptions but didn't find</div><div style="margin: 0px;">> > > >>>> them</div><div style="margin: 0px;">> > > >>>> outside of the code. Double btw: There is a documentation bug in</div><div style="margin: 0px;">> > > >>>> the</div><div style="margin: 0px;">> > > >>>> source here in that the five /** … */ comments need to be trailing</div><div style="margin: 0px;">> > > >>>> /**< … */ comments (Doxygen trailing-member syntax). Right now,</div><div style="margin: 0px;">> > > >>>> when</div><div style="margin: 0px;">> > > >>>> the comments are rendered, they are offset by one.</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Regards,</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> Noah</div><div style="margin: 0px;">> > > >>>> </div><div style="margin: 0px;">> > > >>>> On Sat, Jul 11, 2026 at 8:47 AM Noah <> wrote:</div><div style="margin: 0px;">> > > >>>>> Thanks, John.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>>> Your premise that the database was necessarily written by a</div><div style="margin: 0px;">> > > >>>>>> GnuCash</div><div style="margin: 0px;">> > > >>>>>> session is false.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> You're right, I was biasing by my own use principles.</div><div style="margin: 0px;">> > > >>>>> I never want to modify my production book through anything but the</div><div style="margin: 0px;">> > > >>>>> GnuCash GUI or the official GnuCash API / bindings.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> My household moved our finances to GnuCash 14 years ago motivated</div><div style="margin: 0px;">> > > >>>>> by</div><div style="margin: 0px;">> > > >>>>> two challenges.</div><div style="margin: 0px;">> > > >>>>> - need to support two users on different computers (in serial, not</div><div style="margin: 0px;">> > > >>>>> simultaneously). We were bit too many times with filesystem-based</div><div style="margin: 0px;">> > > >>>>> commercial options at the time.</div><div style="margin: 0px;">> > > >>>>> - a Q* commercial software was dropping support for Mac, or</div><div style="margin: 0px;">> > > >>>>> non-cloud, or both</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> In more recent years, our financial institutions have been making</div><div style="margin: 0px;">> > > >>>>> it</div><div style="margin: 0px;">> > > >>>>> harder to get our transaction data into GnuCash (eg. removing</div><div style="margin: 0px;">> > > >>>>> OFX/QFX</div><div style="margin: 0px;">> > > >>>>> download)</div><div style="margin: 0px;">> > > >>>>> In order to hold the line at home, I've been doing more and more</div><div style="margin: 0px;">> > > >>>>> work</div><div style="margin: 0px;">> > > >>>>> adopting use of the API & Python bindings to help a lot in this</div><div style="margin: 0px;">> > > >>>>> regard. I've also been creating some reporting and exploration</div><div style="margin: 0px;">> > > >>>>> tools</div><div style="margin: 0px;">> > > >>>>> that don't need write access (and tinkering with other's work like</div><div style="margin: 0px;">> > > >>>>> piecash). Since they don’t need write access, I want them to</div><div style="margin: 0px;">> > > >>>>> access</div><div style="margin: 0px;">> > > >>>>> MySQL with the minimum privileges necessary.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>>> The ffastmath problem underlying bug 611936 was on the write side</div><div style="margin: 0px;">> > > >>>>>> of</div><div style="margin: 0px;">> > > >>>>>> libdii so a read-only test wouldn’t find the problem.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> That settles it for me: since the -ffast-math defect in #611936 is</div><div style="margin: 0px;">> > > >>>>> on</div><div style="margin: 0px;">> > > >>>>> the write side of libdbi, a read-only session can neither trigger</div><div style="margin: 0px;">> > > >>>>> nor</div><div style="margin: 0px;">> > > >>>>> detect it, so running the probe on a read-only open guards</div><div style="margin: 0px;">> > > >>>>> nothing.</div><div style="margin: 0px;">> > > >>>>> I've opened a PR that skips dbi_library_test() for</div><div style="margin: 0px;">> > > >>>>> SESSION_READ_ONLY</div><div style="margin: 0px;">> > > >>>>> and leaves all write-capable modes untouched:</div><div style="margin: 0px;">> > > >>>>> https://github.com/Gnucash/gnucash/pull/2266</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> I'm not trying to bolt access control onto GnuCash, and I agree</div><div style="margin: 0px;">> > > >>>>> that</div><div style="margin: 0px;">> > > >>>>> wouldn't end well. The narrower goal is just to let a read-only</div><div style="margin: 0px;">> > > >>>>> consumer honor a least-privilege credential a DBA may already have</div><div style="margin: 0px;">> > > >>>>> in</div><div style="margin: 0px;">> > > >>>>> place -- and, independently, to stop running a write-only probe on</div><div style="margin: 0px;">> > > >>>>> a</div><div style="margin: 0px;">> > > >>>>> read-only open. The PR stands on that second part alone.</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> Thanks again,</div><div style="margin: 0px;">> > > >>>>> Noah</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> On Thu, Jul 9, 2026 at 8:31 PM John Ralls</div><div style="margin: 0px;">> > > >>>>> </div><div style="margin: 0px;">> > > >>>>> <jralls_at_ceridwen_us_pgk183pwhb49kj_sc4m4741@icloud.com> wrote:</div><div style="margin: 0px;">> > > >>>>>>> On Jul 9, 2026, at 14:34, array_hourly_0u@icloud.com wrote:</div><div style="margin: 0px;">> > > >>>>>>> Hello again,</div><div style="margin: 0px;">> > > >>>>>>> Obviously backend stuff is on my mind lately and there's been a</div><div style="margin: 0px;">> > > >>>>>>> quirk impacting read-only access to SQL back-ed books that has</div><div style="margin: 0px;">> > > >>>>>>> bothered me for a while.</div><div style="margin: 0px;">> > > >>>>>>> Opening a book with SESSION_READ_ONLY through the SQL/DBI</div><div style="margin: 0px;">> > > >>>>>>> backend</div><div style="margin: 0px;">> > > >>>>>>> still requires the database user to have permission to create a</div><div style="margin: 0px;">> > > >>>>>>> temporary table. On every session_begin (regardless of mode),</div><div style="margin: 0px;">> > > >>>>>>> dbi_library_test() runs the 64-bit round-trip guard from Bug</div><div style="margin: 0px;">> > > >>>>>>> #611936</div><div style="margin: 0px;">> > > >>>>>>> -- CREATE TEMPORARY TABLE / INSERT / SELECT / DROP -- to detect</div><div style="margin: 0px;">> > > >>>>>>> a</div><div style="margin: 0px;">> > > >>>>>>> 15-year-old -ffast-math libdbi miscompilation. A</div><div style="margin: 0px;">> > > >>>>>>> least-privileged,</div><div style="margin: 0px;">> > > >>>>>>> SELECT-only database user therefore cannot open the book at all:</div><div style="margin: 0px;">> > > >>>>>>> the</div><div style="margin: 0px;">> > > >>>>>>> create fails and begin returns ERR_SQL_DBI_UNTESTABLE.</div><div style="margin: 0px;">> > > >>>>>>> (SESSION_READ_ONLY already skips the gnclock lock, so this probe</div><div style="margin: 0px;">> > > >>>>>>> is</div><div style="margin: 0px;">> > > >>>>>>> the only remaining reason a read-only open needs write-ish</div><div style="margin: 0px;">> > > >>>>>>> rights.)</div><div style="margin: 0px;">> > > >>>>>>> I'd like to propose making a read-only open work without those</div><div style="margin: 0px;">> > > >>>>>>> privileges. Two possible directions:</div><div style="margin: 0px;">> > > >>>>>>> 1. Skip dbi_library_test() when the session is opened</div><div style="margin: 0px;">> > > >>>>>>> SESSION_READ_ONLY.</div><div style="margin: 0px;">> > > >>>>>>> 2. Or, for read-only, replace it with a check that needs no</div><div style="margin: 0px;">> > > >>>>>>> write</div><div style="margin: 0px;">> > > >>>>>>> privileges -- for example, verify the driver retrieves large</div><div style="margin: 0px;">> > > >>>>>>> int64/uint64 and a high-precision FLOAT8 via a SELECT of</div><div style="margin: 0px;">> > > >>>>>>> literals/casts (dbi_result_get_longlong / get_ulonglong /</div><div style="margin: 0px;">> > > >>>>>>> get_double),</div><div style="margin: 0px;">> > > >>>>>>> so the reader's conversion path is still validated. I'd welcome</div><div style="margin: 0px;">> > > >>>>>>> suggestions on the best minimal form.</div><div style="margin: 0px;">> > > >>>>>>> The justification for either approach: the data already in the</div><div style="margin: 0px;">> > > >>>>>>> database was written by a GnuCash session, and</div><div style="margin: 0px;">> > > >>>>>>> dbi_library_test()</div><div style="margin: 0px;">> > > >>>>>>> ran</div><div style="margin: 0px;">> > > >>>>>>> for that session, so any book that was successfully saved was</div><div style="margin: 0px;">> > > >>>>>>> necessarily saved by a driver that passed the round-trip test --</div><div style="margin: 0px;">> > > >>>>>>> the</div><div style="margin: 0px;">> > > >>>>>>> stored 64-bit and FLOAT8 values are therefore correct at rest. A</div><div style="margin: 0px;">> > > >>>>>>> read-only session never writes back, so the only thing left to</div><div style="margin: 0px;">> > > >>>>>>> guard</div><div style="margin: 0px;">> > > >>>>>>> against is a reader-side retrieval defect. For a modern 64-bit</div><div style="margin: 0px;">> > > >>>>>>> libdbi</div><div style="margin: 0px;">> > > >>>>>>> that is the 2011, 32-bit / -ffast-math case from #611936, which</div><div style="margin: 0px;">> > > >>>>>>> is</div><div style="margin: 0px;">> > > >>>>>>> essentially historical (or maybe never existed on the read)</div><div style="margin: 0px;">> > > >>>>>>> If there is a preferred direction, I'm happy to prepare a PR.</div><div style="margin: 0px;">> > > >>>>>> </div><div style="margin: 0px;">> > > >>>>>> Your premise that the database was necessarily written by a</div><div style="margin: 0px;">> > > >>>>>> GnuCash</div><div style="margin: 0px;">> > > >>>>>> session is false. Anybody with db write access (and for a SQLite3</div><div style="margin: 0px;">> > > >>>>>> database that means anyone with write access to the filesystem)</div><div style="margin: 0px;">> > > >>>>>> can</div><div style="margin: 0px;">> > > >>>>>> write (or delete) whatever they want into the database. There is</div><div style="margin: 0px;">> > > >>>>>> at</div><div style="margin: 0px;">> > > >>>>>> least one public Python library that reads and writes GnuCash</div><div style="margin: 0px;">> > > >>>>>> SQLite3 files (https://github.com/sdementen/piecash). The</div><div style="margin: 0px;">> > > >>>>>> databases</div><div style="margin: 0px;">> > > >>>>>> have no integrity checks enabled: Any integrity checking (and</div><div style="margin: 0px;">> > > >>>>>> it’s</div><div style="margin: 0px;">> > > >>>>>> pretty minimal) is in GnuCash’s engine.</div><div style="margin: 0px;">> > > >>>>>> </div><div style="margin: 0px;">> > > >>>>>> The ffastmath problem underlying bug 611936 was on the write side</div><div style="margin: 0px;">> > > >>>>>> of</div><div style="margin: 0px;">> > > >>>>>> libdii so a read-only test wouldn’t find the problem. I think it</div><div style="margin: 0px;">> > > >>>>>> unlikely that anyone is using that version of gcc anymore so it’s</div><div style="margin: 0px;">> > > >>>>>> probably safe to remove the test.</div><div style="margin: 0px;">> > > >>>>>> </div><div style="margin: 0px;">> > > >>>>>> That said, I have my doubts about the value of having users</div><div style="margin: 0px;">> > > >>>>>> without</div><div style="margin: 0px;">> > > >>>>>> database write access. Access control hasn’t ever been a</div><div style="margin: 0px;">> > > >>>>>> consideration in GnuCash’s design and trying to bolt it on 30</div><div style="margin: 0px;">> > > >>>>>> years</div><div style="margin: 0px;">> > > >>>>>> later isn’t likely to produce a satisfactory result.</div><div style="margin: 0px;">> > > >>>>>> </div><div style="margin: 0px;">> > > >>>>>> Regards,</div><div style="margin: 0px;">> > > >>>>>> John Ralls</div><div style="margin: 0px;">> > > >>> </div><div style="margin: 0px;">> > > >>> _______________________________________________</div><div style="margin: 0px;">> > > >>> gnucash-devel mailing list</div><div style="margin: 0px;">> > > >>> gnucash-devel@gnucash.org</div><div style="margin: 0px;">> > > >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel</div><div style="margin: 0px;">> > > > </div><div style="margin: 0px;">> > > > _______________________________________________</div><div style="margin: 0px;">> > > > gnucash-devel mailing list</div><div style="margin: 0px;">> > > > gnucash-devel@gnucash.org</div><div style="margin: 0px;">> > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel</div>
<br><br></div>
</div></blockquote></div><br></div></body></html>