<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 22:01:17 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[CXX-1066] Audit all libmongoc and libbson calls for error handling</title>
                <link>https://jira.mongodb.org/browse/CXX-1066</link>
                <project id="11980" key="CXX">C++ Driver</project>
                    <description>&lt;p&gt;We&apos;ve seen several cases where libmongoc or libbson calls aren&apos;t checked for errors in the return value or in out parameters.  We should audit every single call to confirm that if errors are possible that we are handling them.&lt;/p&gt;</description>
                <environment></environment>
        <key id="320711">CXX-1066</key>
            <summary>Audit all libmongoc and libbson calls for error handling</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="sam.rossi@mongodb.com">Samuel Rossi</assignee>
                                    <reporter username="david.golden@mongodb.com">David Golden</reporter>
                        <labels>
                    </labels>
                <created>Tue, 4 Oct 2016 00:10:00 +0000</created>
                <updated>Wed, 5 Jul 2017 16:29:06 +0000</updated>
                            <resolved>Wed, 24 May 2017 20:42:04 +0000</resolved>
                                                    <fixVersion>3.2.0-rc0</fixVersion>
                                    <component>Implementation</component>
                                        <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="1579425" author="sam.rossi" created="Wed, 24 May 2017 20:41:51 +0000"  >&lt;p&gt;From discoveries made while auditing the calls in bsoncxx, I filed &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2169&quot; title=&quot;Return value for bson_decimal128_from_string is undocumented&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2169&quot;&gt;&lt;del&gt;CDRIVER-2169&lt;/del&gt;&lt;/a&gt; and &lt;a href=&quot;https://jira.mongodb.org/browse/CXX-1347&quot; title=&quot;Calls to bson_append_* are not checked for errors in the core builder&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CXX-1347&quot;&gt;&lt;del&gt;CXX-1347&lt;/del&gt;&lt;/a&gt;. Since all of the code has now been audited, I&apos;m closing this ticket.&lt;/p&gt;</comment>
                            <comment id="1549734" author="david.golden" created="Fri, 14 Apr 2017 19:25:50 +0000"  >&lt;p&gt;Remaining work: review bsoncxx calls to libbson and file tickets for any issues found.&lt;/p&gt;</comment>
                            <comment id="1530913" author="david.golden" created="Thu, 23 Mar 2017 02:10:48 +0000"  >&lt;p&gt;Filed &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2095&quot; title=&quot;Document what false means as return value&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2095&quot;&gt;&lt;del&gt;CDRIVER-2095&lt;/del&gt;&lt;/a&gt; and made it a dependency.&lt;/p&gt;</comment>
                            <comment id="1432528" author="rassi@10gen.com" created="Fri, 11 Nov 2016 23:23:10 +0000"  >&lt;p&gt;Note for the eventual assignee of this ticket: bsoncxx::document::view::find() &lt;a href=&quot;https://github.com/mongodb/mongo-cxx-driver/blob/master/src/bsoncxx/document/view.cpp#L126-L132&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;initializes its bson_iter_t twice&lt;/a&gt;, and bsoncxx::array::view::find() does as well.  These second initializations are redundant, and should potentially be removed as part of implementing this ticket.&lt;/p&gt;</comment>
                            <comment id="1432413" author="rassi@10gen.com" created="Fri, 11 Nov 2016 21:42:50 +0000"  >&lt;p&gt;I filed an improvement request for bson_iter_init_find() and bson_iter_init_find_case() at &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-1916&quot; title=&quot;bson_iter_init_find() and bson_iter_init_find_case() should return false only when iterator is successfully exhausted and key not found&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-1916&quot;&gt;&lt;del&gt;CDRIVER-1916&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="1428082" author="david.golden" created="Mon, 7 Nov 2016 16:40:54 +0000"  >&lt;p&gt;We&apos;ll do that when we do the audit.&lt;/p&gt;</comment>
                            <comment id="1428047" author="jesse" created="Mon, 7 Nov 2016 16:27:47 +0000"  >&lt;p&gt;Feel free to open a ticket with specific functions you&apos;d like improved docs for.&lt;/p&gt;</comment>
                            <comment id="1428024" author="behackett" created="Mon, 7 Nov 2016 16:16:40 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=driver-c%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;driver-c@mongodb.com&quot;&gt;driver-c@mongodb.com&lt;/a&gt;, is there a CDRIVER ticket to document error handling for the public API?&lt;/p&gt;</comment>
                            <comment id="1427979" author="david.golden" created="Mon, 7 Nov 2016 15:51:31 +0000"  >&lt;p&gt;I think we should move away from ambiguous functions like &lt;tt&gt;bson_iter_init_find&lt;/tt&gt; and use the separate underlying calls.&lt;/p&gt;

&lt;p&gt;Thus, I think we need to check every &lt;tt&gt;mongoc&lt;/tt&gt; function individually to ensure that we understand failure vs error and whether we are handling them appropriately.&lt;/p&gt;

&lt;p&gt;Having the C driver better documented about what failure means would help.  As written, &lt;tt&gt;bson_iter_init&lt;/tt&gt; should only return false if the provided &lt;tt&gt;bson_t&lt;/tt&gt; is less than the minimum size.  If we could rely on that to always be the case for that function, we could maintain that invariant ourselves.&lt;/p&gt;</comment>
                            <comment id="1426796" author="rassi@10gen.com" created="Fri, 4 Nov 2016 21:27:21 +0000"  >&lt;p&gt;You&apos;re totally right, I did misunderstand.  Ugh, that&apos;s a rather unhelpful contract for bson_iter_init_find() to have.  Imagine if the read() system call collapsed a return value of -1 and 0 into the same value.  I wonder if we should ask the C driver team to provide stronger guarantees of the circumstances under which bson_iter_init() / bson_init_static() / etc will succeed, or if we should ask them to change the return types of these to void and to assert that initialization succeeded with BSON_ASSERT().  We could also avoid using bson_iter_init_find(), but I&apos;m not sure how many other API methods have a similarly ambiguous return value.&lt;/p&gt;</comment>
                            <comment id="1425760" author="david.golden" created="Thu, 3 Nov 2016 22:45:56 +0000"  >&lt;p&gt;I think you&apos;re confusing my two thoughts.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;There are some cases where we can&apos;t tell if a false return value is an error or a failure.  Consider &lt;a href=&quot;http://mongoc.org/libbson/current/bson_iter_init_find.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;bson_iter_init_find&lt;/a&gt;.  It could return false because initialization failed (an error) or because the key was not found (a failure).  We need to be careful about blanket application of something like wrappers because of ambiguities of this type.  I think we have to audit calls individually and make sure we know exactly what &quot;error&quot; and &quot;failure&quot; are for each call.&lt;/li&gt;
	&lt;li&gt;If you feel strongly about checking always vs once, then I suggest we find a way to cache the objects so we&apos;re not calling repeatedly.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="1424130" author="rassi@10gen.com" created="Wed, 2 Nov 2016 16:38:56 +0000"  >&lt;p&gt;Here are a couple of thoughts about how to reduce the amount of boilerplate required for handling libbson errors:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Provide our own throwing wrappers around libbson API calls.&lt;/li&gt;
	&lt;li&gt;Assert with developer invariants that certain libbson API calls always succeed (for example, if a previous call to bson_init_static() succeeded with the same arguments).  We currently don&apos;t have any developer invariant utility functions in the C++ driver as far as I can tell, but I think it would be a good idea to introduce them.  Note also that libbson calls abort() when the condition passed to any BSON_ASSERT() statement evaluates so false, so there would be precedent for the C++ driver to call std::abort() when a developer invariant is violated.&lt;/li&gt;
&lt;/ol&gt;
</comment>
                            <comment id="1424089" author="rassi@10gen.com" created="Wed, 2 Nov 2016 16:09:05 +0000"  >&lt;p&gt;I disagree that &quot;failure&quot; and &quot;error&quot; can be reasonably distinguished here.  Even if a call to bson_init_static() with some three arguments returned true at one point, a subsequent call to bson_init_static() with the exact same three arguments could return false, even in the current stable version of libbson (for example, if the data pointed to by the second parameter was modified inbetween calls, perhaps as part of an exploit of some application vulnerability).  In addition, if any future version of libbson changes the implementation of bson_init_static() such that a new error branch is introduced, it would not be a backwards-breaking change according to its documented behavior, and we wouldn&apos;t necessarily hear about it.&lt;/p&gt;

&lt;p&gt;More generally, it&apos;s an important secure programming practice to handle any documented error conditions from API calls (&lt;a href=&quot;https://cwe.mitre.org/data/definitions/252.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;mitre.org: Unchecked Return Value&lt;/a&gt;).  Note also that doing so will avoid us having to maintain a lengthy warnings whitelist once we integrate a static analysis tool into our CI process (&lt;a href=&quot;https://jira.mongodb.org/browse/CXX-526&quot; title=&quot;Enable coverity for legacy and master branches&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CXX-526&quot;&gt;&lt;del&gt;CXX-526&lt;/del&gt;&lt;/a&gt;).&lt;/p&gt;</comment>
                            <comment id="1423892" author="david.golden" created="Wed, 2 Nov 2016 14:04:05 +0000"  >&lt;p&gt;I suspect you&apos;re right, but we need to be careful to distinguish when their return values are &quot;failure&quot; vs &quot;error&quot;.  I also think there are some cases where we should check &lt;b&gt;once&lt;/b&gt; on initialization and then not check again (possibly caching the libbson data structures).  E.g. calling &lt;tt&gt;bson_static_init&lt;/tt&gt; over and over isn&apos;t going to give a different answer, but I hate seeing it unchecked because I don&apos;t know for certain whether and where it&apos;s been checked.&lt;/p&gt;</comment>
                            <comment id="1423847" author="rassi@10gen.com" created="Wed, 2 Nov 2016 13:32:39 +0000"  >&lt;p&gt;Implementation thoughts: I suggest we should throw an exception if calls to libbson API functions return an error, such as bson_init_static() or bson_iter_init().  If one of these function calls fails, we currently tell the user that the operation was successful (in the case of document::view::begin() for example, we give the user the incorrect impression that the document is empty).  Throwing an exception in these cases will increase user application correctness, and increase diagnosability of libbson issues or data corruption issues.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="367187">CDRIVER-2095</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="332290">CXX-1134</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="331371">CDRIVER-1916</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="343927">CXX-1187</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="386655">CXX-1347</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="386647">CDRIVER-2169</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="307142">CXX-984</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrarvj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="1675">Perl/CXX 2017-05-05</customfieldvalue>
    <customfieldvalue id="1715">Perl/CXX 2017-05-26</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>