Bug#913896:

[A. Jesse Jiryu Davis]

I'm a libbson maintainer, and I believe this is only a minor bug, not
a grave vulnerability.

The bug is triggered when libbson reads BSON data corrupted in a
specific manner. The faulty logic will read up to 4 bytes past the end
of a buffer.

This is not a grave vulnerability for two reasons. First, applications
use libbson to read BSON data from trusted sources, either a MongoDB
server or the local file system, not from untrusted sources. We do not
consider a MongoDB server or a filesystem under malicious control to
be an attack vector that we can secure libbson against. Second, when
libbson reads past the end of the buffer, it does nothing with the
data it read: it considers it part of an unstructured binary blob. It
does no further parsing of the data and does not use that data in any
conditional statements or use it as a pointer, so it does not provide
a mechanism for remote code execution or any other type of attack.

Bug#908299: libmongoc-dev has hidden SSL dependence

[A. Jesse Jiryu Davis]

Yes, I agree that these are real use cases for a small number of
users. You can build the C Driver from source, disabling SSL and
crypto libraries, following these instructions:

http://mongoc.org/libmongoc/current/installing.html#building-on-unix
On Mon, Sep 10, 2018 at 3:35 AM Dmitriy Gerasimov
 wrote:
>
> Thank you for your reply, Jesse. Yes you're right 99% of users don't
> need special build of libmongoc without TLS.
>
> Unfortunatelly we are from this 1%. Lof of goverment organizations and
> some big corporations uses its own cryptography and/or encryption protocols.
>
> We develop our own C framework with Post-Quantum encryption and no-TLS
> protocols. https://github.com/kelvinblockchain/libdap
>
> Its opensource but also there are some private projects based on same
> code, like fast and secure VPN server. It uses mongo as backend database
> and we connect to the Mongo only via
> https://github.com/kelvinblockchain/libdap-stream and
> https://github.com/kelvinblockchain/libdap-stream-ch-vpn things. They
> encrypt the connection so we're interested may be ever in no-network
> builds because we could forward unix sockets as well.
>
> So there are use cases for such requirements. Also intersting would be
> to have no-network variant of MongoDB server that works only through
> local sockets.
>
>
> On 08.09.2018 19:13, A. Jesse Jiryu Davis wrote:
> > Hi Dmitriy, libmongoc uses libssl and libcrypto for a variety of
> > purposes, not just for TLS-encrypted network connections. It uses
> > libcrypto for authentication with a password-protected MongoDB server,
> > and to generate the tokens used in transactions. Besides,
> > TLS-encrypted network connections are now extremely common: Atlas and
> > other cloud providers require TLS, and any time you connect to a
> > MongoDB server outside your internal secure network you must use TLS.
> >
> > For these reasons we thought it simple and worthwhile to always
> > require libssl and libcrypto. Most users will be happy that the
> > default installation of libmongoc has all the capabilities they need.
> >
> > You're right, the libmongoc-ssl-1.0 pkg-config file is the same as the
> > libmongoc-1.0 pkg-config file. We'd like to remove libmongoc-ssl-1.0,
> > but that's a backward-breaking change so we won't do it until version
> > 2.0: see https://jira.mongodb.org/browse/CDRIVER-2086
> >
> > On Sat, Sep 8, 2018 at 3:15 AM Dmitriy Gerasimov
> >  wrote:
> >> Package: libmongoc-dev
> >> Version: 1.4.2-1+b1  (possible other versions too)
> >>
> >> Ever I don't want to use the SSL I need to install libssl-dev to build 
> >> packages that uses pkg-config to be builded with libmongoc-dev.
> >> If we look at the output of `pkg-config' we see no difference between 
> >> `libmongoc-1.0' and `libmongoc-ssl-1.0' profiles.
> >>
> >> $ pkg-config --libs libmongoc-1.0
> >> -lmongoc-1.0 -lssl -lcrypto -lrt -lbson-1.0
> >>
> >> $ pkg-config --libs libmongoc-ssl-1.0
> >> -lmongoc-1.0 -lssl -lcrypto -lrt -lbson-1.0
> >>
> >>
> >> I suggest to remove -lssl and -lcrypto from `libmongoc-1.0' profile
> >>
> >> I am using Debian GNU/Linux 9.5, kernel 4.9.110-3+deb9u4 and libc6 
> >> 2.24-11+deb9u3
>

Bug#908299: libmongoc-dev has hidden SSL dependence

[A. Jesse Jiryu Davis]

Hi Dmitriy, libmongoc uses libssl and libcrypto for a variety of
purposes, not just for TLS-encrypted network connections. It uses
libcrypto for authentication with a password-protected MongoDB server,
and to generate the tokens used in transactions. Besides,
TLS-encrypted network connections are now extremely common: Atlas and
other cloud providers require TLS, and any time you connect to a
MongoDB server outside your internal secure network you must use TLS.

For these reasons we thought it simple and worthwhile to always
require libssl and libcrypto. Most users will be happy that the
default installation of libmongoc has all the capabilities they need.

You're right, the libmongoc-ssl-1.0 pkg-config file is the same as the
libmongoc-1.0 pkg-config file. We'd like to remove libmongoc-ssl-1.0,
but that's a backward-breaking change so we won't do it until version
2.0: see https://jira.mongodb.org/browse/CDRIVER-2086

On Sat, Sep 8, 2018 at 3:15 AM Dmitriy Gerasimov
 wrote:
>
> Package: libmongoc-dev
> Version: 1.4.2-1+b1  (possible other versions too)
>
> Ever I don't want to use the SSL I need to install libssl-dev to build 
> packages that uses pkg-config to be builded with libmongoc-dev.
> If we look at the output of `pkg-config' we see no difference between 
> `libmongoc-1.0' and `libmongoc-ssl-1.0' profiles.
>
> $ pkg-config --libs libmongoc-1.0
> -lmongoc-1.0 -lssl -lcrypto -lrt -lbson-1.0
>
> $ pkg-config --libs libmongoc-ssl-1.0
> -lmongoc-1.0 -lssl -lcrypto -lrt -lbson-1.0
>
>
> I suggest to remove -lssl and -lcrypto from `libmongoc-1.0' profile
>
> I am using Debian GNU/Linux 9.5, kernel 4.9.110-3+deb9u4 and libc6 
> 2.24-11+deb9u3

Bug#906687: pymongo breaks python-motor autopkgtest

[A. Jesse Jiryu Davis]

Hi, I'm the upstream author of Motor. Motor is 2.0 now and its tests
work with PyMongo 3.7.1 in my testing systems. I've only been testing
the latest Motor against recent PyMongo versions; I haven't tested
older Motor with the latest PyMongo. Does Motor 2.0's test suite pass
with the PyMongo 3.7.1 Debian package?

Bug#896204:

[A. Jesse Jiryu Davis]

It looks like this package should depend on python3-pymongo.

Bug#878343:

[A. Jesse Jiryu Davis]

forwarded https://jira.mongodb.org/browse/CDRIVER-2325

Bug#878343: libmongoc-dev: "pkg-config --libs libmongoc-1.0" returns -lsnappy but no dependency on libsnappy-dev

[A. Jesse Jiryu Davis]

Thanks, we'll fix for 1.8.1.

Bug#876194:

[A. Jesse Jiryu Davis]

forwarded https://jira.mongodb.org/browse/CDRIVER-2286

Bug#876194: libbson-dev: Please install the cmake package config file

[A. Jesse Jiryu Davis]

forward: https://jira.mongodb.org/browse/CDRIVER-2286

Bug#874754:

[A. Jesse Jiryu Davis]

Here's a patch from Kevin Albertson that applies the fix to libbson 1.4.2.


0001-CDRIVER-2269-Check-for-zero-string-length-in-codewsc.patch
Description: Binary data

Bug#874754: libbson: CVE-2017-14227

[A. Jesse Jiryu Davis]

Thanks, we've diagnosed the bug and we're tracking the fix in
https://jira.mongodb.org/browse/CDRIVER-2269 . We'll release the fix
in libbson 1.8.0 next week.

On Sat, Sep 9, 2017 at 11:36 AM, Salvatore Bonaccorso  wrote:
> Some debugging information:
>
> =
> ==7414==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x61900980 at pc 0x555759b3 bp 0x7fffd9b0 sp 0x7fffd9a8
> READ of size 1 at 0x61900980 thread T0
> #0 0x555759b2 in _bson_utf8_get_sequence src/bson/bson-utf8.c:49
> #1 0x55575c3b in bson_utf8_validate src/bson/bson-utf8.c:131
> #2 0x5556cbf4 in bson_iter_visit_all src/bson/bson-iter.c:2069
> #3 0x555607d5 in bson_metrics examples/bson-metrics.c:208
> #4 0x55560b01 in main examples/bson-metrics.c:257
> #5 0x7f8775da02e0 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
> #6 0xfce9 in _start (/root/libbson/bson-metrics+0xbce9)
>
> 0x61900980 is located 0 bytes to the right of 1024-byte region 
> [0x61900580,0x61900980)
> allocated by thread T0 here:
> #0 0x7f8776717bb8 in __interceptor_calloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9bb8)
> #1 0x5556eb0c in bson_malloc0 src/bson/bson-memory.c:105
> #2 0x55571614 in bson_reader_new_from_handle 
> src/bson/bson-reader.c:173
> #3 0x55571a2a in bson_reader_new_from_fd src/bson/bson-reader.c:304
> #4 0x555731d4 in bson_reader_new_from_file src/bson/bson-reader.c:806
> #5 0x555609fe in main examples/bson-metrics.c:244
> #6 0x7f8775da02e0 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow src/bson/bson-utf8.c:49 in 
> _bson_utf8_get_sequence
> Shadow bytes around the buggy address:
>   0x0c327fff80e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c327fff80f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c327fff8100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c327fff8110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c327fff8120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c327fff8130:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c327fff8140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c327fff8150: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c327fff8160: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c327fff8170: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c327fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
> ==7414==ABORTING
> [
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f8775db442a in __GI_abort () at abort.c:89
> #2  0x7f877673741b in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.4
> #3  0x7f877673ebb8 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.4
> #4  0x7f8776721a8d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.4
> #5  0x7f87767224e8 in __asan_report_load1 () from 
> /usr/lib/x86_64-linux-gnu/libasan.so.4
> #6  0x555759b3 in _bson_utf8_get_sequence (utf8=0x61900980 "",
> seq_length=0x7fffda90 "\001\220VUUU", first_mask=0x7fffda50 
> "\177\005")
> at src/bson/bson-utf8.c:49
> #7  0x55575c3c in bson_utf8_validate (utf8=0x6190058e "\006", 
> utf8_len=4294967295,
> allow_null=true) at src/bson/bson-utf8.c:131
> #8  0x5556cbf5 in bson_iter_visit_all (iter=0x7fffe680,
> visitor=0x557a4a20 , data=0x557ad960 
> )
> at src/bson/bson-iter.c:2069
> #9  0x555607d6 in bson_metrics (bson=0x613000c0, length=0x0,
> data=0x557ad960 ) at examples/bson-metrics.c:208
> #10 0x55560b02 in main (argc=2, argv=0x7fffebe8) at 
> examples/bson-metrics.c:257
>
> and
>
> (gdb) list src/bson/bson-iter.c:2069
> 2064 uint32_t doclen = 0;
> 2065 bson_t b;
> 2066
> 2067 code = bson_iter_codewscope (iter, , , 
> );
> 2068
> 2069 if (!bson_utf8_validate (code, length, true)) {
> 2070 

Bug#860241: Thanks

[A. Jesse Jiryu Davis]

Thanks for the patch and sorry for the bug, we'll fix this in the next
couple weeks.

Bug#854130: libbson FTBFS on mips/mipsel: test-results.json aborted

[A. Jesse Jiryu Davis]

Thanks Radovan. I plan to upload 1.6.1 to Debian soon (via my sponsor
Roberto Sanchez) so let's do that instead of backporting.

Bug#854130: libbson FTBFS on mips/mipsel: test-results.json aborted

[A. Jesse Jiryu Davis]

Thanks that's useful info! Roberto Sanchez and I logged into a MIPS
machine on Tuesday and we found corroborating evidence which I wrote
up in the forwarded ticket:

https://jira.mongodb.org/browse/CDRIVER-2053

The problem is, the test suite starts hundreds of threads. I think the
solution is to run single-threaded, as you say, since that's simplest
and easiest to debug if a test fails in the future. Out of curiosity,
we'll also test a version that limits concurrency to 10 threads.

On Thu, Feb 16, 2017 at 10:18 AM, James Cowgill  wrote:
> Hi,
>
> On Sat, 04 Feb 2017 14:01:10 +0200 Adrian Bunk  wrote:
>> Source: libbson
>> Version: 1.5.0-1
>> Severity: serious
>>
>> https://buildd.debian.org/status/package.php?p=libbson=sid
>>
>> ...
>> { "status": "PASS", "test_file": "/bson/utf8/from_unichar", "seed": 
>> "3897722749", "start": 918303.161886737, "end": 918303.161907618, "elapsed": 
>> 0.20881 },
>> { "status": "PASS", "test_file": "/bson/utf8/invalid", "seed": 
>> "3495301312", "start": 918303.172066716, "end": 918303.172096569, "elapsed": 
>> 0.29853 },
>> { "status": "PASS", "test_file": 
>> "/bson/decimal128/from_string/exponent_normalization", "seed": "2524386511", 
>> "start": 918303.160139775, "end": 918303.172289377, "elapsed": 0.012149602 },
>> { "status": "PASS", "test_file": "/bson/as_json/stack_overflow", "seed": 
>> "4062366096", "start": 918303.082477899, "end": 918303.199222704, "elapsed": 
>> 0.116744805 },
>> { "status": "PASS", "test_file": "/type/decimal128/decimal128-2", 
>> "seed": "973167199", "start": 918303.151844572, "end": 918303.202736059, 
>> "elapsed": 0.050891487 },
>> { "status": "PASS", "test_file": "/type/decimal128/decimal128-3", 
>> "seed": "3407436287", "start": 918303.160160818, "end": 918303.227553065, 
>> "elapsed": 0.067392247 },
>> { "status": "PASS", "test_file": "/bson/as_json/x1000", "seed": 
>> "3264176593", "start": 918303.082226314, "end": 918303.360835632, "elapsed": 
>> 0.278609318 },
>> /bin/bash: line 1:  2488 Aborted /bin/bash ./libtool 
>> --mode=execute $VALGRIND ./$TEST_PROG --threads --no-fork -F 
>> test-results.json
>
> Backtrace:
> Thread 232 "test-libbson" received signal SIGABRT, Aborted.
> [Switching to Thread 0x444e4a0 (LWP 20412)]
> __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:58
> 58  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1  0x77de4e74 in __GI_abort () at abort.c:89
> #2  0x77f9186c in bson_realloc (mem=, num_bytes= out>) at src/bson/bson-memory.c:153
> #3  0x77f7fb4c in _bson_impl_alloc_grow (size=, 
> impl=0x55b00518) at src/bson/bson.c:175
> #4  _bson_grow (bson=0x55b00518, size=) at src/bson/bson.c:209
> #5  0x77f810f8 in _bson_append_va (args=0x444d7cc, first_data=0x77f99183 
>  "\022bson_append_int64", first_len=1, n_pairs=4, n_bytes= out>, bson=0x55b00518) at src/bson/bson.c:313
> #6  _bson_append (bson=0x55b00518, n_pairs=4, n_bytes=, 
> first_len=1, first_data=0x77f99183  "\022bson_append_int64") at 
> src/bson/bson.c:392
> #7  0x77f82d34 in bson_append_int64 (bson=0x55b00518, key=, 
> key_length=, value=271) at src/bson/bson.c:1153
> #8  0x55573be8 in test_bson_writer_shared_buffer () at tests/test-writer.c:83
> #9  0x4564 in TestSuite_RunTest (suite=0x7fff6ae4, test=0x555a8fc0, 
> mutex=0x7fff69fc, count=0x7fff69f8) at tests/TestSuite.c:444
> #10 0x47cc in TestSuite_ParallelWorker (data=0x555cf3a8) at 
> tests/TestSuite.c:645
> #11 0x77f3b8c0 in start_thread (arg=0x0) at pthread_create.c:335
> #12 0x77ea39e4 in __thread_start () at 
> ../sysdeps/unix/sysv/linux/mips/clone.S:143
>
> The abort call in frame #2 is due to running out of memory and indeed
> running libbson through strace shows that mmap returns ENOMEM just
> before aborting.
>
> libbson appears to use up all of the MIPS virtual address space. MIPS
> was hit first because it only has 2GB of virtual memory (whereas most
> other 32-bit Linux arches have 3GB). The correct fix would be to try
> and reduce the amount of memory allocated - it seems that a lot of the
> memory being allocated is never used anyway.
>
> Making the testsuite run single threaded (as was mentioned on the
> upstream bug report) may workaround this. Possibly the amount of memory
> allocated increases the more threads are in use?
>
> Thanks,
> James
>

Bug#840528:

[A. Jesse Jiryu Davis]

Thanks Andreas, you're right. We'll submit 1.4.2 with the fix promptly.

On Wed, Oct 26, 2016 at 6:34 PM, Andreas Beckmann <a...@debian.org> wrote:

> Control: reopen -1
>
> On Wed, 12 Oct 2016 22:00:26 -0400 "A. Jesse Jiryu Davis" <
> je...@mongodb.com> wrote:
> > Version: 1.4.1-1
>
> Nope.
>
> > Fixed in the upstream repository and uploaded as a new package version to
> > Debian. See the forwarded-to bug in MongoDB's Jira for details.
>
> That new version is not yet in Debian. Jira says fixed in 1.4.2.
>
> Also:
>
> $ echo '#include ' | gcc -x c -I /usr/include/libmongoc-1.0 -c -
> In file included from :1:0:
> /usr/include/libmongoc-1.0/mongoc.h:22:18: fatal error: bson.h: No such
> file or directory
>  #include 
>   ^
> compilation terminated.
>
>
> Andreas
>

Bug#833409: libbson: please make the build reproducible

[A. Jesse Jiryu Davis]

Thanks, as with Bug#831659 for the dependent library libmongoc, I've
filed this upstream here:

https://jira.mongodb.org/browse/CDRIVER-1399

It's fixed in upstream and will be released in the next couples weeks
as libbson 1.4.0 and libmongoc 1.4.0, and re-uploaded to Debian.

On Wed, Aug 3, 2016 at 8:18 PM, Chris Lamb  wrote:
> Source: libbson
> Version: 1.3.5-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the "reproducible builds" effort [0], we noticed
> that libbson could not be built reproducibly.
>
> Patch attached.
>
>  [0] https://wiki.debian.org/ReproducibleBuilds
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#832747: libbson FTBFS on mipsel and mips: symbols doesn't matching

[A. Jesse Jiryu Davis]

Thanks, I'll take a look right away.

Bug#831659: libmongoc: please make the build reproducible

[A. Jesse Jiryu Davis]

I've filed this upstream here:

https://jira.mongodb.org/browse/CDRIVER-1399

Thanks for the patch! I intend to apply it to libmongoc and its dependency
libbson, which has the same reproducibility issue as libmongoc. We'll
release the fix with the upstream 1.4 package and upload to Debian then, at
the end of this July.

On Mon, Jul 18, 2016 at 5:43 AM, Chris Lamb  wrote:

> Source: libmongoc
> Version: 1.3.5-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the "reproducible builds" effort [0], we noticed
> that libmongoc could not be built reproducibly.
>
> Patch attached.
>
>  [0] https://wiki.debian.org/ReproducibleBuilds
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#828398: libmongoc: FTBFS with openssl 1.1.0

[A. Jesse Jiryu Davis]

Thanks; we're tracking this in the upstream bug tracker here:

https://jira.mongodb.org/browse/CDRIVER-1066

On Sun, Jun 26, 2016 at 6:22 AM, Kurt Roeckx  wrote:
> Source: libmongoc
> Version: 1.3.5-1
> Severity: important
> Control: block 827061 by -1
>
> Hi,
>
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/libmongoc_1.3.5-1_amd64-20160529-1442
>
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of 
> the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful 
> information.
>
> There is a libssl-dev package available in experimental that contains a recent
> snapshot, I suggest you try building against that to see if everything works.
>
> If you have problems making things work, feel free to contact us.
>
>
> Kurt

Bug#812948: libbson-doc: contains manpages with generic names: index(3), installing(3)

[A. Jesse Jiryu Davis]

Thanks; I'm fixing the upcoming libbson upstream release 1.4.0 to prefix
all our man pages with "bson_", so "clock.3" will be "bson_clock.3".
That'll be released in a month or two and we'll update the Debian package.

On Wed, May 18, 2016 at 2:33 AM, Ralf Treinen  wrote:

> Hi,
>
> libbson-doc also ships
>
>   /usr/share/man/man3/clock.3.gz
>
> which also exists in manpages-dev. -Ralf.
>

Bug#812949: Will fix this upstream in libmongoc

[A. Jesse Jiryu Davis]

I've opened a libmongoc bug to fix the man page names in the source repo:

https://jira.mongodb.org/browse/CDRIVER-1077

(I'm using a single issue in MongoDB's bug tracker for both the
libbson and libmongoc work.)

Bug#812948: Will fix this upstream in libbson

[A. Jesse Jiryu Davis]

I've opened a libbson bug to fix the man page names in the source repo:

https://jira.mongodb.org/browse/CDRIVER-1077

Bug#798695: libbson packaging

[A. Jesse Jiryu Davis]

Hi Laszlo, our intent at MongoDB is to work with a consultant, Roberto
Sanchez, to create and maintain the libbson package ourselves. Same for
libmongoc, the actual MongoDB C Driver, which depends on libbson.

We've put some effort into this package ourselves now. I'm very sorry to
hear about the duplicated work. If you're willing to share your 90%-done
libbson package with us, however, I think it would be very helpful and we
could take advantage of your hard work!

By the way, removing yajl from the source tree is necessary, but not quite
sufficient. libbson includes private headers from yajl and access private
data in one place, libbson's _bson_json_read_parse_error function. Have you
come up with a solution to this already?

Thank you,
Jesse



On Sun, Sep 13, 2015 at 4:14 AM, László Böszörményi  wrote:

> Hi Jesse,
>
> Thanks for bringing this up. I'm the maintainer of MongoDB in Debian.
> Always wanted to package libbson and other libraries / utilities
> around it. Now took my time and it's about 90% ready. I need to remove
> the yayl library from the source tree and build with the system
> provided one.
> My question is, do you want to do it alone or either let me do it or
> do it together?
>
> Regards,
> Laszlo/GCS
>

Bug#798711: ITP: libmongoc -- MongoDB C client library

[A. Jesse Jiryu Davis]

Package: wnpp
Severity: wishlist
Owner: "A. Jesse Jiryu Davis" <je...@mongodb.com>

* Package name: libmongoc
  Version : 1.3.0
  Upstream Author : A. Jesse Jiryu Davis <je...@mongodb.com>
* URL : https://github.com/mongodb/mongo-c-driver
* License : Apache 2
  Programming Lang: C
  Description : MongoDB C client library

libmongoc is the officially supported MongoDB client library for C
applications, and the foundation for certain MongoDB drivers written
in higher-level languages like C++ and PHP.

Bug#798695: ITP: libbson -- Library to parse and generate BSON documents

[A. Jesse Jiryu Davis]

Package: wnpp
Severity: wishlist
Owner: "A. Jesse Jiryu Davis" <je...@mongodb.com>

* Package name: libbson
  Version : 1.3.0
  Upstream Author : A. Jesse Jiryu Davis <je...@mongodb.com>
* URL : https://github.com/mongodb/libbson
* License : Apache 2
  Programming Lang: C
  Description : Library to parse and generate BSON documents

libbson parses and generates BSON documents, the data format for
MongoDB. It is a dependency for libmongoc, the MongoDB client library,
for which it provides BSON support as well as platform-compatibility
functions and macros.