profile
viewpoint

estk/log4rs 385

A highly configurable logging framework for Rust

a8m/pb 337

Console progress bar for Rust

env-logger-rs/env_logger 234

A logging implementation for `log` which is configured via an environment variable.

pyfisch/cbor 215

CBOR support for serde.

gnzlbg/jemallocator 192

Rust allocator using jemalloc as a backend

carllerche/syncbox 129

Concurrency utilities for Rust

kornelski/rust-security-framework 84

Bindings to the macOS Security.framework

rust-lang-nursery/unix-socket 51

Unix socket support for Rust

issue closedsfackler/rust-native-tls

openssl_probe::init_ssl_cert_env_vars

openssl_probe::init_ssl_cert_env_vars() now returns a bool which fails to compile at this line:

https://github.com/sfackler/rust-native-tls/blob/master/src/imp/openssl.rs#L94

   |
94 |     ONCE.call_once(|| openssl_probe::init_ssl_cert_env_vars());
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `bool`

closed time in 3 hours

vkandy

issue commentsfackler/rust-native-tls

openssl_probe::init_ssl_cert_env_vars

That is a break in openssl_probe, and the release has been yanked.

vkandy

comment created time in 3 hours

Pull request review commentHomebrew/homebrew-core

Update RocksDB to 6.11.4

 def install                                 "-std=c++11", "-stdlib=libc++", "-lstdc++",                                 "-lz", "-lbz2",                                 "-L#{lib}", "-lrocksdb_lite",+                                "-DROCKSDB_LITE=1",

This fixes the test failures in earlier attempts to upgrade (e.g. #56602).

sfackler

comment created time in 7 hours

PR opened Homebrew/homebrew-core

Update RocksDB to 6.11.4
  • [ ] Have you followed the guidelines for contributing?
  • [ ] Have you checked that there aren't other open pull requests for the same formula update/change?
  • [ ] Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
  • [ ] Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
  • [ ] Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

+5 -4

0 comment

1 changed file

pr created time in 7 hours

push eventsfackler/homebrew-core

Steven Fackler

commit sha c3035f5bb082251749035e376732ed84b4563f40

Update RocksDB to 6.11.4

view details

push time in 7 hours

create barnchsfackler/homebrew-core

branch : rocks-6114

created branch time in 7 hours

fork sfackler/homebrew-core

🍻 Default formulae for the missing package manager for macOS

https://brew.sh

fork in 7 hours

delete branch sfackler/official-images

delete branch : rust-1452

delete time in 10 hours

issue commentsfackler/rust-postgres

connection parameters

Is it the case that the prepared statement on the server is scoped to a connection?

Yes

Can you point me to where this is done in this library?

https://github.com/sfackler/rust-postgres/blob/master/tokio-postgres/src/prepare.rs

If you're using pgbouncer in transaction pooling mode, you'd either need to make sure you're in a transaction whenever making a query with a prepared statement, or use the simple_query method to avoid prepared statements entirely, though there are significant limitations to that.

scirner22

comment created time in a day

create barnchsfackler/official-images

branch : rust-1452

created branch time in a day

push eventrust-lang/docker-rust

Steven Fackler

commit sha d237d8c30f57d55f70bbc019da2f24d371050947

Update to 1.45.2

view details

push time in a day

issue commentsfackler/rust-postgres

connection parameters

That code already uses a server-side prepared statement. As that page says, prepareThreshold=0 disables server-side prepared statements entirely. Unlike JDBC, this library does not perform client-side parameter expansion.

scirner22

comment created time in a day

issue commentalexcrichton/openssl-src-rs

Can I somehow point other sys crates (during compile time) to the libs build by this crate?

You would need to update that other crate to optionally depend on openssl-src. Once it does that, it can pick up the install path and set OPENSSL_ROOT_DIR properly for cmake in its build script.

svanharmelen

comment created time in a day

issue commentsfackler/rust-postgres

connection parameters

What is the behavior you are seeing, and what is the behavior you want? I am not personally familiar with the JDBC driver.

scirner22

comment created time in a day

pull request commentrust-lang/rust

Slice strip

r? @rust-lang/docs

ijackson

comment created time in 2 days

issue commentsfackler/rust-openssl

Does not compile on termux on Android (aarch64)

Install pkg-config.

matu3ba

comment created time in 2 days

issue closedsfackler/rust-openssl

openssl-sys constantly being rebuilt on Nix(OS)

On NixOS, to build openssl-sys you must be in a temporary environment where pkg-config and openssl are presents and their environment variables too (such as PKG_CONFIG_PATH), using nix-shell -p pkg-config openssl --run 'cargo build'.

Previously, running this command once to build the crate was enough, I could then leave the environment and use cargo commands normally. But now (probably since a recent update ?) every time I leave the shell, and use cargo run/build, the crate gets recompiled (and fails because pkg-config is missing). Apparently, the fact the PKG_CONFIG_PATH environment variable changed triggers that rebuild.

As my IDE runs clippy on the fly (and so, without the appropriate environment to build openssl-sys), this feature becomes unusable as soon as openssl-sys gets in my project dependencies :/ I also can't use the run button from my IDE anymore.

What changed in the build process so that it has to rely on such environment variables ? Is there any workaround ? Thanks by advance

closed time in 3 days

Litarvan

issue commentsfackler/rust-openssl

openssl-sys constantly being rebuilt on Nix(OS)

That is due to https://github.com/rust-lang/pkg-config-rs/pull/105.

Litarvan

comment created time in 3 days

pull request commentsfackler/rust-postgres

Give a more helpful message on error

Thanks!

jyn514

comment created time in 3 days

push eventsfackler/rust-postgres

Joshua Nelson

commit sha ce7ce310b91bd24d80bd98c4e267d2b14ae4220c

Give a more helpful message on error Before: ``` database error: ERROR: insert or update on table "owner_rels" violates foreign key constraint "owner_rels_cid_fkey" ``` After: ``` database error: ERROR: insert or update on table "owner_rels" violates foreign key constraint "owner_rels_cid_fkey" DETAIL: Key (cid)=(4) is not present in table "releases". ```

view details

Joshua Nelson

commit sha 61f6e3e5c49390ab43035a222f67976814525e41

Add newline before DETAIL and HINT

view details

Steven Fackler

commit sha fc131afa9c5d5c88f254edb7af3699bbe609dc20

Merge pull request #645 from jyn514/display Give a more helpful message on error

view details

push time in 3 days

PR merged sfackler/rust-postgres

Give a more helpful message on error

Before:

database error: ERROR: insert or update on table "owner_rels" violates foreign key constraint "owner_rels_cid_fkey"

After:

database error: ERROR: insert or update on table "owner_rels" violates foreign key constraint "owner_rels_cid_fkey"
DETAIL:  Key (cid)=(4) is not present in table "releases".

Warning: this is completely untested except for cargo check, I didn't see existing tests for Display and docs.rs is still stuck on 0.15.

+8 -1

0 comment

1 changed file

jyn514

pr closed time in 3 days

Pull request review commentrust-lang/rust

Add Vec::spare_capacity_mut

 impl<T> Vec<T> {     {         Box::leak(vec.into_boxed_slice())     }++    /// Returns the remaining spare capacity of the vector as a slice of+    /// `MaybeUninit<T>`.+    ///+    /// The return slice can be used to fill the vector with data (e.g. by
    /// The returned slice can be used to fill the vector with data (e.g. by
Amanieu

comment created time in 3 days

Pull request review commentrust-lang/rust

Add Vec::spare_capacity_mut

 impl<T> Vec<T> {     {         Box::leak(vec.into_boxed_slice())     }++    /// Returns the remaining spare capacity of the vector as a slice of+    /// `MaybeUninit<T>`.+    ///+    /// The return slice can be used to fill the vector with data (e.g. by+    /// reading from a file) before marking the data as initialized using the+    /// [`set_len`] method.+    ///+    /// [`set_len`]: #method.set_len+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(vec_spare_capacity, maybe_uninit_extra)]+    ///+    /// // Allocate vector big enough for 10 elements.
    /// // Allocate vector big enough for 4 elements.
Amanieu

comment created time in 3 days

pull request commentrust-lang/rust

Add Vec::spare_capacity_mut

Nice! r=me with a tracking issue.

Amanieu

comment created time in 3 days

Pull request review commentsfackler/rust-postgres

Give a more helpful message on error

 impl DbError {  impl fmt::Display for DbError {     fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {-        write!(fmt, "{}: {}", self.severity, self.message)+        write!(fmt, "{}: {}", self.severity, self.message)?;+        if let Some(detail) = &self.detail {+            write!(fmt, "DETAIL: {}", detail)?;

Shouldn't there be some whitespace before DETAIL and HINT?

jyn514

comment created time in 3 days

issue commenttokio-rs/tokio

Tokio panicking

bytes should be handling the 4GB limit in the implementation of bytes_vectored.

andrewbanchich

comment created time in 4 days

issue commentsfackler/rust-openssl

Build script C macro expansion error for cross compiled OpenSSL

Given that the alpha releases are still making ABI breaks, I think I'm going to avoid landing that PR until a stable 3.0.0 is released. I'll keep the branch updated so if you need to run against 3.0.0 in the meantime, you can use [patch.crates-io] to switch over to it temporarily.

repnop

comment created time in 4 days

issue commentsfackler/rust-postgres

Typed prepared statement with array of integers params

Yeah, ANY() is the right thing to use there.

apiraino

comment created time in 4 days

issue commentsfackler/rust-postgres

RETURNING id

rust-postgres is a wrapper over tokio-postgres, so I do not believe that is the case.

If you could provide a minimal reproduction of the problem, that would be helpful.

glennpierce

comment created time in 4 days

pull request commentsfackler/rust-postgres

Use checked arithmetic when decoding into chrono types

Thanks!

benesch

comment created time in 4 days

push eventsfackler/rust-postgres

Nikhil Benesch

commit sha a30f0b6c0586e467cd48d759b903eb8d4ec7c3e7

Use checked arithmetic when decoding into chrono types This avoids an overflow panic if the timestamp is the special "infinity" or "-infinity" value and produces an error instead. Fix #640.

view details

Steven Fackler

commit sha 286b9dcd0a82d864129025ca64cd614e7adafa7e

Merge pull request #641 from benesch/infinity-overflow Use checked arithmetic when decoding into chrono types

view details

push time in 4 days

PR merged sfackler/rust-postgres

Use checked arithmetic when decoding into chrono types

This avoids an overflow panic if the timestamp is the special "infinity" or "-infinity" value and produces an error instead.

Fix #640.

+41 -3

0 comment

2 changed files

benesch

pr closed time in 4 days

issue commentsfackler/rust-postgres

built-in tracing support

Sure, I'd be happy to take a PR!

jbg

comment created time in 5 days

issue commentsfackler/rust-native-tls

Certificate error when domain name contains underscore

This would be a bug in OpenSSL, not this library.

joshua-maros

comment created time in 5 days

delete branch sfackler/official-images

delete branch : rust-1451

delete time in 5 days

PR opened docker-library/official-images

Update Rust to 1.45.1

We'll be dropping stretch images starting with 1.46.0, but I'm leaving them here since this is a patch release off of 1.45.0.

+19 -19

0 comment

1 changed file

pr created time in 5 days

create barnchsfackler/official-images

branch : rust-1451

created branch time in 5 days

push eventrust-lang/docker-rust

Steven Fackler

commit sha 0345665196e5c245fb0f58f5fb93f85f24890222

Update to 1.45.1

view details

push time in 5 days

issue openedopenssl/openssl

[3.0.0] Concurrent OSSL_PROVIDER_load calls are not properly synchronized

Here's a simple program that just spawns 2 threads, both of which try to load the legacy provider:

#include <openssl/provider.h>
#include <openssl/err.h>
#include <pthread.h>

#define THREADS 2

void *thread(void *arg) {
	if (!OSSL_PROVIDER_load(NULL, "legacy")) {
		ERR_print_errors_fp(stdout);
	}
}

int main() {
	pthread_t threads[THREADS];

	for (int i = 0; i < THREADS; i++) {
		pthread_create(&threads[i], NULL, thread, NULL);
	}

	for (int i = 0; i < THREADS; i++) {
		pthread_join(threads[i], NULL);
	}
}

Running this with 1 thread succeeds, but running it with more causes a wide variety of failures:

Both threads fail and the program exits:

00D716D1967F0000:error::DSO support routines:dlfcn_bind_func:the meth_data stack is corrupt:crypto/dso/dso_dlfcn.c:180:
00D716D1967F0000:error::DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:188:
00D716D1967F0000:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:523:
00E796D1967F0000:error::DSO support routines:dlfcn_load:the meth_data stack is corrupt:crypto/dso/dso_dlfcn.c:130:
00E796D1967F0000:error::DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:164:
00E796D1967F0000:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:523:

One thread reports errors and the other hits an infinite loop in stack internals:

00A7BB12E37F0000:error::DSO support routines:dlfcn_bind_func:the meth_data stack is corrupt:crypto/dso/dso_dlfcn.c:180:
00A7BB12E37F0000:error::DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:188:
00A7BB12E37F0000:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:523:
(gdb) bt
#0  0x00000000004088d7 in compute_growth (target=201341281, current=0) at crypto/stack/stack.c:147
#1  0x00000000004089f3 in sk_reserve (st=0x7fe30c0008d0, n=1, exact=0) at crypto/stack/stack.c:190
#2  0x0000000000408b7b in OPENSSL_sk_insert (st=0x7fe30c0008d0, data=0x7fe30400bed0, loc=201341280) at crypto/stack/stack.c:241
#3  0x0000000000408f3c in OPENSSL_sk_push (st=0x7fe30c0008d0, data=0x7fe30400bed0) at crypto/stack/stack.c:329
#4  0x00000000005a8722 in sk_void_push (sk=0x7fe30c0008d0, ptr=0x7fe30400bed0) at crypto/dso/dso_dlfcn.c:22
#5  0x00000000005a8880 in dlfcn_load (dso=0x7fe30400bd20) at crypto/dso/dso_dlfcn.c:129
#6  0x00000000004969e0 in DSO_load (dso=0x7fe30400bd20, filename=0x7fe30400bde0 "\200\v", meth=0x0, flags=0) at crypto/dso/dso_lib.c:163
#7  0x0000000000406a04 in provider_activate (prov=0x7fe30400bc60) at crypto/provider_core.c:504
#8  0x0000000000406daf in ossl_provider_activate (prov=0x7fe30400bc60) at crypto/provider_core.c:620
#9  0x000000000040571d in OSSL_PROVIDER_load (libctx=0x0, name=0x66b010 "legacy") at crypto/provider.c:24
#10 0x0000000000404101 in thread ()
#11 0x00007fe312d91432 in start_thread () from /lib64/libpthread.so.0
#12 0x00007fe312cbf913 in clone () from /lib64/libc.so.6

Invalid realloc:

00878B3D487F0000:error::DSO support routines:dlfcn_bind_func:the meth_data stack is corrupt:crypto/dso/dso_dlfcn.c:180:
00878B3D487F0000:error::DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:188:
00878B3D487F0000:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:523:
realloc(): invalid pointer
(gdb) bt
#0  0x00007f483e0f99e5 in raise () from /lib64/libc.so.6
#1  0x00007f483e0e2895 in abort () from /lib64/libc.so.6
#2  0x00007f483e13d857 in __libc_message () from /lib64/libc.so.6
#3  0x00007f483e144d7c in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f483e149f1a in realloc () from /lib64/libc.so.6
#5  0x0000000000404b66 in CRYPTO_realloc (str=0x7f483e2fad10, num=9873359888, file=0x66b508 "crypto/stack/stack.c", line=197) at crypto/mem.c:214
#6  0x0000000000408a3f in sk_reserve (st=0x7f483e2b0000, n=1, exact=0) at crypto/stack/stack.c:197
#7  0x0000000000408b7b in OPENSSL_sk_insert (st=0x7f483e2b0000, data=0x7f483800f020, loc=1042976768) at crypto/stack/stack.c:241
#8  0x0000000000408f3c in OPENSSL_sk_push (st=0x7f483e2b0000, data=0x7f483800f020) at crypto/stack/stack.c:329
#9  0x00000000005a8722 in sk_void_push (sk=0x7f483e2b0000, ptr=0x7f483800f020) at crypto/dso/dso_dlfcn.c:22
#10 0x00000000005a8880 in dlfcn_load (dso=0x7f483800ee70) at crypto/dso/dso_dlfcn.c:129
#11 0x00000000004969e0 in DSO_load (dso=0x7f483800ee70, filename=0x7f483800ef30 "/home/sfackler/openssl-3.0.0/lib/ossl-modules/legacy.so", meth=0x0, flags=0)
    at crypto/dso/dso_lib.c:163
#12 0x0000000000406a04 in provider_activate (prov=0x7f483800edb0) at crypto/provider_core.c:504
#13 0x0000000000406daf in ossl_provider_activate (prov=0x7f483800edb0) at crypto/provider_core.c:620
#14 0x000000000040571d in OSSL_PROVIDER_load (libctx=0x0, name=0x66b010 "legacy") at crypto/provider.c:24
#15 0x0000000000404101 in thread ()
#16 0x00007f483e290432 in start_thread () from /lib64/libpthread.so.0
#17 0x00007f483e1be913 in clone () from /lib64/libc.so.6

Valgrind reports many errors running the example program as well:

==214670== Memcheck, a memory error detector
==214670== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==214670== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==214670== Command: ./a.out
==214670== 
0087250500000000:error::DSO support routines:dlfcn_bind_func:the meth_data stack is corrupt:crypto/dso/dso_dlfcn.c:180:
==214670== Thread 3:
==214670== Invalid read of size 8
==214670==    at 0x5A886D: dlfcn_load (dso_dlfcn.c:129)
==214670==    by 0x4969DF: DSO_load (dso_lib.c:163)
==214670==    by 0x406A03: provider_activate (provider_core.c:504)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)
==214670==    by 0x4873431: start_thread (in /usr/lib64/libpthread-2.31.so)
==214670==    by 0x498D912: clone (in /usr/lib64/libc-2.31.so)
==214670==  Address 0x527ef78 is 8 bytes inside a block of size 80 free'd
==214670==    at 0x483B9F5: free (vg_replace_malloc.c:538)
==214670==    by 0x404CA7: CRYPTO_free (mem.c:252)
==214670==    by 0x4966E0: DSO_free (dso_lib.c:95)
==214670==    by 0x406B0A: provider_activate (provider_core.c:526)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)
==214670==    by 0x4873431: start_thread (in /usr/lib64/libpthread-2.31.so)
==214670==    by 0x498D912: clone (in /usr/lib64/libc-2.31.so)
==214670==  Block was alloc'd at
==214670==    at 0x483A809: malloc (vg_replace_malloc.c:307)
==214670==    by 0x404A76: CRYPTO_malloc (mem.c:184)
==214670==    by 0x404AA1: CRYPTO_zalloc (mem.c:191)
==214670==    by 0x496369: DSO_new_method (dso_lib.c:29)
==214670==    by 0x496519: DSO_new (dso_lib.c:61)
==214670==    by 0x4068C2: provider_activate (provider_core.c:476)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)
==214670==    by 0x4873431: start_thread (in /usr/lib64/libpthread-2.31.so)
==214670==    by 0x498D912: clone (in /usr/lib64/libc-2.31.so)
==214670== 
==214670== Invalid read of size 4
==214670==    at 0x408F27: OPENSSL_sk_push (stack.c:329)
==214670==    by 0x5A8721: sk_void_push (dso_dlfcn.c:22)
==214670==    by 0x5A887F: dlfcn_load (dso_dlfcn.c:129)
==214670==    by 0x4969DF: DSO_load (dso_lib.c:163)
==214670==    by 0x406A03: provider_activate (provider_core.c:504)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)
==214670==    by 0x4873431: start_thread (in /usr/lib64/libpthread-2.31.so)
==214670==    by 0x498D912: clone (in /usr/lib64/libc-2.31.so)
==214670==  Address 0x527f000 is 0 bytes inside a block of size 32 free'd
==214670==    at 0x483B9F5: free (vg_replace_malloc.c:538)
==214670==    by 0x404CA7: CRYPTO_free (mem.c:252)
==214670==    by 0x4090EF: OPENSSL_sk_free (stack.c:376)
==214670==    by 0x49632C: sk_void_free (dso_lib.c:13)
==214670==    by 0x496680: DSO_free (dso_lib.c:91)
==214670==    by 0x406B0A: provider_activate (provider_core.c:526)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)
==214670==    by 0x4873431: start_thread (in /usr/lib64/libpthread-2.31.so)
==214670==    by 0x498D912: clone (in /usr/lib64/libc-2.31.so)
==214670==  Block was alloc'd at
==214670==    at 0x483A809: malloc (vg_replace_malloc.c:307)
==214670==    by 0x404A76: CRYPTO_malloc (mem.c:184)
==214670==    by 0x404AA1: CRYPTO_zalloc (mem.c:191)
==214670==    by 0x408A92: OPENSSL_sk_new_reserve (stack.c:208)
==214670==    by 0x40881D: OPENSSL_sk_new_null (stack.c:117)
==214670==    by 0x496312: sk_void_new_null (dso_lib.c:13)
==214670==    by 0x4963B9: DSO_new_method (dso_lib.c:34)
==214670==    by 0x496519: DSO_new (dso_lib.c:61)
==214670==    by 0x4068C2: provider_activate (provider_core.c:476)
==214670==    by 0x406DAE: ossl_provider_activate (provider_core.c:620)
==214670==    by 0x40571C: OSSL_PROVIDER_load (provider.c:24)
==214670==    by 0x404100: thread (in /home/sfackler/a.out)

....

Looking at the code, it additionally seems that locks are much two fine grained. For example, OSSL_PROVIDER_load first checks if the provider has already been loaded with ossl_provider_find, and if not then tries to load it with ossl_provider_new: https://github.com/openssl/openssl/blob/48e971dd9f88933a7f77f5051a8b79b9e17892a9/crypto/provider.c#L19-L21. However, no lock is held across both of these calls, so racing threads can both see that it is not loaded, and then both try to load it. This will either cause the one thread to report an error here: https://github.com/openssl/openssl/blob/a57fc73063bee3fb787e583f5778433ef29d58eb/crypto/provider_core.c#L271-L277, or (since the lock still isn't held across that check), the threads will both try to open the library and push it onto the stack.

created time in 5 days

issue commentsfackler/rust-postgres

Cannot start a runtime from within a runtime

Warp's an asynchronous library, so you'll probably want to use tokio-postgres instead.

glennpierce

comment created time in 5 days

issue commentsfackler/rust-postgres

Synchronous `Client` and threads

https://github.com/sfackler/r2d2-postgres

fredfortier

comment created time in 6 days

issue commentsfackler/rust-postgres

Connection attempt hangs indefinetly

Is restarting the instance supposed to cause the issue or fix it? You could try using lsof to see what the status of the TCP socket is, or running with Wireshark to capture the packets.

feikesteenbergen

comment created time in 6 days

issue commentsfackler/rust-postgres

Synchronous `Client` and threads

You could use an Arc and Mutex, or a connection pool like r2d2.

fredfortier

comment created time in 6 days

pull request commentrust-lang/rust

Add std::panic::panic_box.

Why does panic_with_value! need to be a macro at all rather than a normal function?

m-ou-se

comment created time in 6 days

issue commentsfackler/rust-postgres

How should notifications be handled in the sync API?

Implemented in #588

sfackler

comment created time in 7 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha a7066c2a8c5444921aae7820b4371244df5dfb48

Work around upstream base64 bug Closes #1325

view details

push time in 7 days

issue closedsfackler/rust-openssl

Segmentation fault with String when computing base64

The following examples causes a segfault:

fn main() {
    let src = "";
    let res = openssl::base64::decode_block(src).unwrap().to_vec();
    println!("Static: {:?}", res);

    let src = String::from("");
    let res = openssl::base64::decode_block(&src).unwrap().to_vec();
    println!("Dynamic: {:?}", res);
}

playground link

The first computed base64, which uses a static str works, but the second, which uses a borrowed str from a String causes a segfault. This happens with openssl crate 0.10 and from master branch here on git as well.

closed time in 7 days

Jonathas-Conceicao

issue commentsfackler/rust-openssl

Segmentation fault with String when computing base64

This was fixed upstream, but seems reasonable to add a workaround here as well: https://github.com/openssl/openssl/issues/12143.

Jonathas-Conceicao

comment created time in 7 days

issue closedsfackler/rust-openssl

`EcdsaSig::verify` hardcoded to `Public` instead of `T: HasPublic`

Which means verify can't be used with the private key (I'm only guessing that openssl would take the private key too in ECDSA_do_verify of course).

https://github.com/sfackler/rust-openssl/blob/5cf2c2d5f06841a891b3b42c63e7e885c7ec4570/openssl/src/ecdsa.rs#L68

closed time in 7 days

stbuehler

push eventsfackler/rust-openssl

Steven Fackler

commit sha c706d9118874ec51512afe37a33bf3781b7a7ce7

Fix EcdsaSig method flexibility Closes #1323

view details

push time in 7 days

push eventsfackler/rust-postgres

Steven Fackler

commit sha bc682b3103f9a03e4ee1af8881d826f4bffcbf44

Explicitly terminate the connection in sync API Closes #613

view details

push time in 8 days

issue closedsfackler/rust-postgres

Terminate connection to database

Hi there!

Thanks for the rust-postgres is a cool crate 😄

I am building PostgreSQL compatible database and using synchronous Client in my integration tests. I am starting the server in separate thread and facing the problem that I can't terminate connection with Client. I think it's good idea to send terminate message when dropping Client that is not closed. WDYT?

closed time in 8 days

alex-dukhno

pull request commentsfackler/rust-openssl

Make openssl not cleanup at exit, which can lead to race conditions.

cargo:warning=/root/project/target/x86_64-unknown-linux-gnu/debug/build/systest-8e617a442b512dea/out/all.c:11054:77: error: 'OPENSSL_INIT_NO_ATEXIT' undeclared here (not in a function)
cargo:warning=             static const uint64_t __test_const_OPENSSL_INIT_NO_ATEXIT_val = OPENSSL_INIT_NO_ATEXIT;
cargo:warning=                                                                             ^~~~~~~~~~~~~~~~~~~~~~
orium

comment created time in 8 days

pull request commentsfackler/rust-openssl

Initial support for OpenSSL 3.0.0-alpha1

Test failures are due to https://github.com/openssl/openssl/issues/12543.

sfackler

comment created time in 8 days

issue openedopenssl/openssl

[3.0.0] Concurrent namemap initialization races and often fails

Here's a simple C program that spawns 10 threads, each of which create and initialize an EVP_MD_CTX to use SHA1:

#include <openssl/evp.h>
#include <openssl/err.h>
#include <pthread.h>
#include <stdio.h>

#define THREADS 10

void *thread(void *arg) {
	EVP_MD_CTX *ctx = EVP_MD_CTX_create();

	int r = EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
	if (r != 1) {
		ERR_print_errors_fp(stdout);
	}
}

int main() {
	pthread_t threads[THREADS];

	for (int i = 0; i < THREADS; i++) {
		pthread_create(&threads[i], NULL, thread, NULL);
	}

	for (int i = 0; i < THREADS; i++) {
		pthread_join(threads[i], NULL);
	}
}

When run against OpenSSL 3.0.0-alpha5 on a Linux VM with 12 cores, many of the threads report errors initializing OpenSSL's internal namemap:

00B7FFB50C7F0000:error::common libcrypto routines:ossl_namemap_add_names:internal error:crypto/core_namemap.c:310:Got number 12 when expecting 70
00B7FFB50C7F0000:error::common libcrypto routines:ossl_namemap_add_names:internal error:crypto/core_namemap.c:310:Got number 78 when expecting 94
00B7FFB50C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00B7FFB50C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
0097FFB40C7F0000:error::common libcrypto routines:ossl_namemap_add_names:internal error:crypto/core_namemap.c:310:Got number 12 when expecting 71
0097FFB40C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
0097FFB40C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
00A77FB50C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00A77FB50C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
00F7FF9F0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:internal error:crypto/core_namemap.c:310:Got number 12 when expecting 44
00F7FF9F0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:internal error:crypto/core_namemap.c:310:Got number 78 when expecting 79
00F7FF9F0C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00F7FF9F0C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
00F7FFB70C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00F7FFB70C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
00F7FFB70C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00F7FFB70C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
00E77FB70C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00C77FB60C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00C77FB60C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
00C77FB60C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
0027D1BC0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00C77FB60C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
0027D1BC0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
0027D1BC0C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
0027D1BC0C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
00E77FB70C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
00E77FB70C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00E77FB70C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
003751BD0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00D7FFB60C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-1" has an existing different identity 12 (from "SHA1:SHA-1")
00D7FFB60C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
00D7FFB60C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
00D7FFB60C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:
003751BD0C7F0000:error::common libcrypto routines:ossl_namemap_add_names:conflicting names:crypto/core_namemap.c:290:"SHA-512" has an existing different identity 78 (from "SHA2-512:SHA-512:SHA512")
003751BD0C7F0000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto/evp/evp_fetch.c:318:Global default library context, Algorithm (SHA1), Properties ()
003751BD0C7F0000:error::digital envelope routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:178:

The program runs without errors when configured to spawn a single thread, so it seems like the namemap code has some concurrency bugs.

created time in 8 days

issue closedsfackler/rust-openssl

build on windows with static kind

Hi,

I would like to build my program with openssl in static kind. In my openssl-dir I have some files in lib directory like : libcrypto.lib and libcrypto_static.lib. With the master branch rust-openssl link by default with static kind if the build process found libcrypto.lib, but the final exe crash at ssl calling with code 0xC0000005 STATUS_ACCESS_VIOLATION. If I force the build param : cargo:rustc-link-lib={}={}_static, the link process have many errors like : undefined reference to __GSHandlerCheck' undefined reference to __chkstk'. Have you any idea?

Thanks in advance

Cédric

closed time in 11 days

CedricCouton

issue closedsfackler/rust-openssl

Vendored build of LibreSSL?

Would you be open to a PR enabling vendored builds of LibreSSL? I've implemented this on my dev machine (running OSX 10.10), and the build process seems straightforward there. My implementation adds a feature vendored-libre to openssl and openssl-sys, which brings in an external package libressl-src, modeled after openssl-src.

I think there wouldn't be any change to the licensing: it looks like LibreSSL is under the same "OpenSSL license" that OpenSSL is.

I haven't learned how your ci system works, so someone would have to help with that. And for all I know, it may be that configuring and building LibreSSL needs more tweaking to handle some of the targets you support.

closed time in 11 days

dubiousjim

issue commentsfackler/rust-openssl

Vendored build of LibreSSL?

Again, the vendored feature there for people that just want the thing to build. I do not want to support configuration beyond that.

dubiousjim

comment created time in 11 days

issue closedsfackler/rust-openssl

Cannot Build on Ubuntu 20.04

I am currently having issues building on ubuntu 20.04, both using system openssl and using a custom-built copy. Setting OPENSSL_DIR=/usr/local (where openssl is installed), setting it to /usr (where the distro packages are installed) and leaving OPENSSL_DIR unset all cause the same failure.

The pertinent output from cargo is at https://gist.github.com/chorman0773/2fc064147bb98e43491cec9eac6bf1cf (all variations of above return output which is not significantly different).

closed time in 11 days

chorman0773

issue closedsfackler/rust-openssl

windows 10: failed to run custom build command for `openssl-sys v0.9.58`

C:\Users\abc\Documents\rust>cargo build Compiling openssl-sys v0.9.58 Compiling rand_os v0.1.3 Compiling rand_jitter v0.1.4 Compiling num-traits v0.2.12 error: failed to run custom build command for openssl-sys v0.9.58

Caused by: process didn't exit successfully: C:\Users\lakala\Documents\rust\target\debug\build\openssl-sys-0935686155dc6fb8\build-script-main (exit code: 101) --- stdout cargo:rustc-cfg=const_fn cargo:rerun-if-env-changed=X86_64_PC_WINDOWS_MSVC_OPENSSL_LIB_DIR X86_64_PC_WINDOWS_MSVC_OPENSSL_LIB_DIR unset cargo:rerun-if-env-changed=OPENSSL_LIB_DIR OPENSSL_LIB_DIR unset cargo:rerun-if-env-changed=X86_64_PC_WINDOWS_MSVC_OPENSSL_INCLUDE_DIR X86_64_PC_WINDOWS_MSVC_OPENSSL_INCLUDE_DIR unset cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR OPENSSL_INCLUDE_DIR unset cargo:rerun-if-env-changed=X86_64_PC_WINDOWS_MSVC_OPENSSL_DIR X86_64_PC_WINDOWS_MSVC_OPENSSL_DIR unset cargo:rerun-if-env-changed=OPENSSL_DIR OPENSSL_DIR unset note: vcpkg did not find openssl: Could not find library in Vcpkg tree package openssl is not installed for vcpkg triplet x64-windows-static-md

--- stderr thread 'main' panicked at '

Could not find directory of OpenSSL installation, and this -sys crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the OPENSSL_DIR environment variable for the compilation process.

Make sure you also have the development packages of openssl installed. For example, libssl-dev on Ubuntu or openssl-devel on Fedora.

If you're in a situation where you think the directory should be found automatically, please open a bug at https://github.com/sfackler/rust-openssl and include information about your system as well as this message.

$HOST = x86_64-pc-windows-msvc $TARGET = x86_64-pc-windows-msvc openssl-sys = 0.9.58

It looks like you're compiling for MSVC but we couldn't detect an OpenSSL installation. If there isn't one installed then you can try the rust-openssl README for more information about how to download precompiled binaries of OpenSSL:

https://github.com/sfackler/rust-openssl#windows

', C:\Users\lakala.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-sys-0.9.58\build\find_normal.rs:157:5 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish... error: build failed

cargo.toml:

[dependencies] actix-web = "2.0.0" actix-web-httpauth = { git = "https://github.com/actix/actix-web-httpauth" } chrono = { version = "0.4.10", features = ["serde"] } derive_more = "0.99.2" diesel = { version = "1.4.2", features = ["postgres","uuidv07", "r2d2", "chrono"] } dotenv = "0.15.0" futures = "0.3.1" r2d2 = "0.8.8" serde = "1.0" serde_derive = "1.0" serde_json = "1.0" actix-service = "1.0.1" alcoholic_jwt = "1.0.0" reqwest = "0.9.22" actix-rt = "1.0.0"

closed time in 11 days

Foredoomed

issue closedsfackler/rust-openssl

Windows : OpenSSL library directory does not exist: "C:\Program Files\OpenSSL-Win64\lib" (but it does, and contains the right files)

When I run cargo build --release on windows, after having set OPENSSL_DIR, OPENSSL_LIB_DIR and OPENSSL_INCLUDE_DIR, I get the following output :

error: failed to run custom build command for openssl-sys v0.9.58

Caused by: process didn't exit successfully: (path to my program) (exit code: 101) --- stdout cargo:rustc-cfg=const_fn cargo:rerun-if-env-changed=I686_PC_WINDOWS_MSVC_OPENSSL_LIB_DIR I686_PC_WINDOWS_MSVC_OPENSSL_LIB_DIR unset cargo:rerun-if-env-changed=OPENSSL_LIB_DIR OPENSSL_LIB_DIR = "C:\Program Files\OpenSSL-Win64\lib" cargo:rerun-if-env-changed=I686_PC_WINDOWS_MSVC_OPENSSL_INCLUDE_DIR I686_PC_WINDOWS_MSVC_OPENSSL_INCLUDE_DIR unset cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR OPENSSL_INCLUDE_DIR = "C:\Program Files\OpenSSL-Win64\include"

--- stderr thread 'main' panicked at 'OpenSSL library directory does not exist: "C:\Program Files\OpenSSL-Win64\lib"', (path to my program) note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.

warning: build failed, waiting for other jobs to finish... error: build failed.

BUT, C:\Program Files\OpenSSL-Win64\lib DOES EXIST and contains all the right files. I'm running the cmd as administrator. I installed openssl with the precompiled binaries.

closed time in 11 days

Teln0

issue closedsfackler/rust-openssl

Fails to compile on Manjaro Linux with OpenSSL 1.1.1

On Manjaro Linux with OpenSSL 1.1.1, this package fails to compile, with the following error:

  This crate is only compatible with OpenSSL 1.0.1, 1.0.2, and 1.1.0, or LibreSSL,
  but a different version of OpenSSL was found. The build is now aborting due to
  this version mismatch.

I tried following other peoples solutions of providing the environment variable OPENSSL_DIR and pointing it to the OpenSSL installation directory (/usr/lib/openssl/ or similar, /usr/lib/openssl-1.0/ for me?), but it just started throwing a different error:

  thread 'main' panicked at 'OpenSSL library directory does not exist: /usr/lib/openssl-1.0/lib', /home/jack/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.11/build.rs:56:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This confused me a lot, as there is no "lib" dir in OpenSSL for Linux.

I ended up getting the idea to try and install OpenSSL in Wine and see what the directory structure was, and welp, its got all three of the directories that it wanted.

TL;DR: This package might be misidentifying Manjaro Linux as Windows.

closed time in 11 days

K4rakara

push eventsfackler/rust-openssl

Steven Fackler

commit sha 695d5c88e511f34d23e39ffcac69f95a2ba5dba2

fix tests

view details

push time in 11 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha 65b3d03ae80b2350de9c230fc3cfaff492b86981

Work around openssl bug

view details

push time in 11 days

issue openedopenssl/openssl

[3.0.0] Error data flags can carry over from one error to another

Using the 3.0.0-alpha5 release, the flags component of an error is not properly cleared out from the error stack's internal storage. This results in errors created without any string data still report ERR_TXT_STRING and ERR_TXT_MALLOCED if the error's slot in the internal stack previously contained an error with malloced string data.

As an example, here's a simple C program:

#include <openssl/err.h>
#include <stdio.h>

int main() {
    int flags;

    // ERR_raise_data(0, 0, "hello %s", "world");
    // ERR_clear_error();

    ERR_raise(0, 0);
    ERR_get_error_data(NULL, &flags);

    printf("flags: %d\n", flags);
}

If you compile and run that, it prints flags: 0, as expected. However, if you uncomment the two lines that create the earlier error, it now prints flags: 3 (i.e. ERR_TXT_STRING | ERR_TXT_MALLOCED), which is incorrect. The end result is that code that looks at the error sees an empty string for its data, rather than no string at all.

It looks like this is the result of #9459, which avoids deallocating malloced data buffers to avoid allocator traffic. The logic should probably be adjusted to unconditionally clear the flags unconditionally and track the fact that the buffer is still malloced somewhere else.

created time in 11 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha 2ab15f090c762860cc2754f1014652a4dd2817c4

Add circle builds

view details

push time in 11 days

issue commentsfackler/rust-openssl

Unable to cross compile OSX -> x86_64-unknown-linux-musl

You'd use that toolchain to compile OpenSSL from source and then configure the crate to link to it with the OPENSSL_DIR environment variable.

leeola

comment created time in 11 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha f824aecd6643a5164c23bcca3de0e0882d31bfd7

rustfmt

view details

push time in 11 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha 2bc060feb65e05a8e4c69a0b57fbddcf7e6d28ad

Update openssl-errors for 3.0.0

view details

push time in 11 days

issue commentrust-lang/rust

Document FromRawFd unsafety

#74699 would provide a more concrete source of UB if FromRawFd is misused.

mahkoh

comment created time in 11 days

PR closed sfackler/log4rs-routing-appender

bump linked_hashmap to 0.5.3

Linked_hashmap is unsound for versions prior to 0.5.3. This can be found in the advisory. This was found from a crater run. Bumping the dependency so that all dependents end up on a sound version of the crate.

+1 -1

1 comment

1 changed file

Dylan-DPC

pr closed time in 13 days

pull request commentsfackler/log4rs-routing-appender

bump linked_hashmap to 0.5.3

This should be handled by yanking affected versions of linked_hashmap.

Dylan-DPC

comment created time in 13 days

pull request commentrust-lang/rust

Remove Linux workarounds for missing CLOEXEC support

@bors r+

cuviper

comment created time in 13 days

Pull request review commentrust-lang/rust

Remove Linux workarounds for missing CLOEXEC support

 //! symbol, but that caused Debian to detect an unnecessarily strict versioned //! dependency on libc6 (#23628). +// There are a variety of `#[cfg]`s controlling which targets are involved in+// each instance of `weak!` and `syscall!`. Rather than trying to unify all of+// that, we'll just allow that some unix targets don't use this module at all.+#![allow(dead_code, unused_macros)]

A bit unfortunate, but probably cleaner than trying to figure out the exact cfg needed.

cuviper

comment created time in 13 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha 5cf2c2d5f06841a891b3b42c63e7e885c7ec4570

Fix clippy

view details

Steven Fackler

commit sha 0940b294054f7ea56601ec05424861dbf2725570

Merge remote-tracking branch 'origin/master' into openssl-300

view details

push time in 13 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha 5cf2c2d5f06841a891b3b42c63e7e885c7ec4570

Fix clippy

view details

push time in 13 days

push eventsfackler/rust-openssl

Thomas Jespersen

commit sha dd8e53cb0d0934c3387bdd771d9b39e296ad97fe

Fix static build on windows-gnu targets Static builds for *-pc-windows-gnu targets broke, because the linker would look for the incorrect libraries. OpenSSL builds produce libssl.dll rather than ssl.dll which makes the linker unhappy with the normal -lssl -lcrypto [1]. A workaround could be used: export OPENSSL_LIBS="ssl:crypto" but it's arguably better to have the openssl-sys crate do the right thing. [1] http://www.mingw.org/wiki/specify_the_libraries_for_the_linker_to_use

view details

Steven Fackler

commit sha fa6df83fd3f9a4aed04beb1551445df4832418a6

Merge pull request #1265 from omnioiot/windows-gnu-build-simpler Fix static build on windows-gnu targets

view details

Steven Fackler

commit sha d2aefe7afc35ab13e9167c5ed703fd971833e9df

Release openssl-sys v0.9.56

view details

Henrik Böving

commit sha 963e3994a59e9de36967177c4ebc063c33b91293

Add support for AES-OCB mode

view details

Henrik Böving

commit sha f34e9b993ddd522a7181719ab1b978e3a8bccdc8

ocb is only available in openssl 1.1 and later

view details

Charlie Li

commit sha 54fbab73b7a6b334e727511416b677b14dbbb8b7

LibreSSL 3.1 branch marked as stable; add support

view details

Steven Fackler

commit sha 95c0866c1d2f051c9120ee40be673e803021eb1b

Merge pull request #1271 from vishwin/master Support LibreSSL 3.1.x

view details

Henrik Böving

commit sha 33f06b767f525c89c76a5fa80b0609042f76839c

remove any from openssl110 cfgs

view details

Steven Fackler

commit sha 41ab7f37a5182db4ed55a216990e1268edf27bc6

Merge pull request #1270 from hargoniX/master Add support for AES-OCB mode

view details

Steven Fackler

commit sha 72048765c7dc70d8a5e9e7b9b1a475b7c47a9261

Release openssl-sys v0.9.57

view details

Steven Fackler

commit sha 406031991ff3d25e33ca7c74ac1c3790b303e67a

Run rustfmt on github actions

view details

Steven Fackler

commit sha f401ba2ec1957cecbe98b81afd9a188f76052883

Run clippy

view details

Steven Fackler

commit sha 00e909849c487bc5d6c7cefc233880633cb23557

Merge pull request #1277 from sfackler/github-actions Start moving to GitHub actions

view details

Steven Fackler

commit sha e851708589d652c7653b4957c390e279d4b2860e

Add SslRef::set_mtu

view details

Steven Fackler

commit sha 1b64b68ac44bfe7a33b234e10684c3d9552a7538

Merge pull request #1280 from sfackler/set-mtu Add SslRef::set_mtu

view details

Steven Fackler

commit sha b34f3e8d299dd791d76a05d9975ecd0e864bd408

asdf

view details

Steven Fackler

commit sha 8909396836014945a1063fa23acb1d8daf27a51c

Move min-version to github actions

view details

Steven Fackler

commit sha 63928bdaaf027050eee98250e539d455c001559c

fix syntax

view details

Steven Fackler

commit sha 7446f9fa683c6c2e173a98125fd5445eae9e481e

Merge pull request #1281 from sfackler/github-actions More GitHub actions

view details

Jacob Hoffman-Andrews

commit sha 6482f419b859c146467f06b63fb937dfab5f5caa

Add Debug trait for X509 and other types. This currently leaves out at least two useful things: - The detailed SubjectPublicKeyInfo, e.g. the modulus of RSA keys. - Extensions.

view details

push time in 13 days

push eventsfackler/rust-openssl

Steven Fackler

commit sha d081c2b596e013b5e392ff9b9f84f2d6890beabb

Update to 3.0.0-alpha5

view details

push time in 13 days

issue closedsfackler/rust-openssl

panic when sending request

I generated self signed certs by doing

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

then I'm following the example provided and I did

let mut acceptor = SslAcceptor::mozilla_intermediate(SslMethod::tls())?;
            acceptor.set_private_key_file(&server.settings.ssl.key, SslFiletype::PEM)?;
            acceptor.set_certificate_chain_file(&server.settings.ssl.cert)?;
            let acceptor = acceptor.build();
            while let Some(stream) = StreamExt::next(&mut listener).await {
                let server_clone = Arc::clone(&server);
                let acceptor = acceptor.clone();
                tokio::spawn(async move {
                    match stream {
                        Ok(value) => {
                            let stream = tokio_openssl::accept(&acceptor, value).await;
                            match stream {
                                Ok(stream_ssl) => {
                                    Self::catch_request(stream_ssl, server_clone).await;
                                }
                                Err(e) => println!("{:#?}", e), // error comes here
                            }
                        }
                        Err(e) => println!("{:?}", e),
                    };
                });
            }

the error:

Failure(
    MidHandshakeSslStream {
        stream: SslStream {
            stream: TcpStream {
                addr: V4(
                    127.0.0.1:8000,
                ),
                peer: V4(
                    127.0.0.1:41402,
                ),
                fd: 7,
            },
            ssl: Ssl {
                state: "error",
                verify_result: X509VerifyResult {
                    code: 0,
                    error: "ok",
                },
            },
        },
        error: Error {
            code: ErrorCode(
                1,
            ),
            cause: Some(
                Ssl(
                    ErrorStack(
                        [
                            Error {
                                code: 336130204,
                                library: "SSL routines",
                                function: "ssl3_get_record",
                                reason: "http request",
                                file: "ssl/record/ssl3_record.c",
                                line: 321,
                            },
                        ],
                    ),
                ),
            ),
        },
    },
)

is this a bug? What am I doing wrong? This is what prints immediately you send the request. Any help will be appreciated

closed time in 13 days

Daksh14

issue commentsfackler/rust-openssl

panic when sending request

As the error message says, the client does not trust the server's certificate.

Daksh14

comment created time in 13 days

push eventsfackler/rust-log-panics

Michel Alexandre Salim

commit sha 9bd0f737ef1f8c3b1077fa44029f7ef604bae9c1

Bump env_logger dependency to 0.7 Works without any code change: https://koji.fedoraproject.org/koji/taskinfo?taskID=46288084 ``` Doc-tests log-panics Running `/usr/bin/rustdoc --crate-type lib --test /builddir/build/BUILD/log-panics-2.0.0/src/lib.rs --crate-name log_panics -L dependency=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps -L dependency=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps --extern env_logger=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/libenv_logger-8c3416e891a85a35.rlib --extern log=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/liblog-cf6b4a0e1628a84c.rlib --extern log_panics=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/liblog_panics-c3ea93e8275695be.rlib` ``` Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>

view details

Michel Alexandre Salim

commit sha 509d9be82e0e708d94c8fe70b223118f8ca14a58

Bump Rust version in CircleCI config Also fix cache path typo Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>

view details

Steven Fackler

commit sha f62a5851e621733bee541ee13de982c6e62abe77

Merge pull request #6 from michel-slm/bump-deps Bump env_logger dependency to 0.7

view details

push time in 13 days

PR merged sfackler/rust-log-panics

Bump env_logger dependency to 0.7

Works without any code change:

https://koji.fedoraproject.org/koji/taskinfo?taskID=46288084

   Doc-tests log-panics
     Running `/usr/bin/rustdoc --crate-type lib --test /builddir/build/BUILD/log-panics-2.0.0/src/lib.rs --crate-name log_panics -L dependency=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps -L dependency=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps --extern env_logger=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/libenv_logger-8c3416e891a85a35.rlib --extern log=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/liblog-cf6b4a0e1628a84c.rlib --extern log_panics=/builddir/build/BUILD/log-panics-2.0.0/target/release/deps/liblog_panics-c3ea93e8275695be.rlib`

Signed-off-by: Michel Alexandre Salim michel@michel-slm.name

<!-- Reviewable:start -->

This change is <img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/> <!-- Reviewable:end -->

+4 -4

3 comments

2 changed files

michel-slm

pr closed time in 13 days

issue commentsfackler/rust-openssl

panic when sending request

The client is sending a raw (unencrypted) HTTP request.

Daksh14

comment created time in 13 days

pull request commentsfackler/rust-postgres

Configuration to disable internal stmt cache

Rather than having a separate mode that has to be enabled, it seems like it could be cleaner to just have some logic to detect if the typeinfo query fails because the statement isn't live and re-prepare it at that point.

pimeys

comment created time in 13 days

issue commentsfackler/rust-openssl

Fails to compile on Manjaro Linux with OpenSSL 1.1.1

The current release of tungstenite depends on a up-to-date version of native-tls.

K4rakara

comment created time in 14 days

Pull request review commentrust-lang/rust

Remove Linux workarounds for missing CLOEXEC support

 use crate::io::{self, IoSlice, IoSliceMut}; use crate::mem;-use crate::sync::atomic::{AtomicBool, Ordering}; use crate::sys::fd::FileDesc; use crate::sys::{cvt, cvt_r}; -use libc::c_int;- //////////////////////////////////////////////////////////////////////////////// // Anonymous pipes ////////////////////////////////////////////////////////////////////////////////  pub struct AnonPipe(FileDesc);  pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> {-    syscall! { fn pipe2(fds: *mut c_int, flags: c_int) -> c_int }-    static INVALID: AtomicBool = AtomicBool::new(false);-     let mut fds = [0; 2];      // Unfortunately the only known way right now to create atomically set the

It's probably not unfortunate anymore now that we can assume the existence of pipe2 :P

cuviper

comment created time in 14 days

Pull request review commentrust-lang/rust

Remove Linux workarounds for missing CLOEXEC support

 impl FileDesc {     pub fn duplicate(&self) -> io::Result<FileDesc> {         // We want to atomically duplicate this file descriptor and set the         // CLOEXEC flag, and currently that's done via F_DUPFD_CLOEXEC. This-        // flag, however, isn't supported on older Linux kernels (earlier than-        // 2.6.24).-        //-        // To detect this and ensure that CLOEXEC is still set, we-        // follow a strategy similar to musl [1] where if passing-        // F_DUPFD_CLOEXEC causes `fcntl` to return EINVAL it means it's not-        // supported (the third parameter, 0, is always valid), so we stop-        // trying that.-        //-        // Also note that Android doesn't have F_DUPFD_CLOEXEC, but get it to

Is this note about android not relevant anymore?

cuviper

comment created time in 14 days

issue commentsfackler/rust-openssl

Fails to compile on Manjaro Linux with OpenSSL 1.1.1

It appears that you are using an outdated copy of rust-openssl that does not support OpenSSL 1.1.1.

K4rakara

comment created time in 14 days

issue commentsfackler/rust-openssl

Unable to build against Android NDK since 0.10.30 with min API < 23

It's probably best to file this on the openssl-src repository then.

Mygod

comment created time in 14 days

issue commentsfackler/rust-openssl

Windows : OpenSSL library directory does not exist: "C:\Program Files\OpenSSL-Win64\lib" (but it does, and contains the right files)

It looks like you have quotes in the value of the environment variable.

Teln0

comment created time in 16 days

pull request commentrust-lang/rust

Add Atomic*::from_mut.

On i686-unknown-linux-gnu, u64 is 4-byte aligned while AtomicU64 is 8-byte aligned: https://rust.godbolt.org/z/6n4dsr

m-ou-se

comment created time in 16 days

issue closedsfackler/rust-openssl

Failed to build on WSL; can't find openssl installation

When running in a Ubuntu WSL2 environment in Windows 10, openssl-sys fails to build with the following message:

thread 'main' panicked at '

Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
compilation process.

Make sure you also have the development packages of openssl installed.
For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.

$HOST = x86_64-unknown-linux-gnu
$TARGET = x86_64-unknown-linux-gnu
openssl-sys = 0.9.58


It looks like you're compiling on Linux and also targeting Linux. Currently this
requires the `pkg-config` utility to find OpenSSL but unfortunately `pkg-config`
could not be found. If you have OpenSSL installed you can likely fix this by
installing `pkg-config`.

', /home/nathan/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.58/build/find_normal.rs:157:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

System information:

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/nathan/.rustup

stable-x86_64-unknown-linux-gnu (default)
rustc 1.45.0 (5c1f21c3b 2020-07-13)

$ sudo apt install libssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libssl-dev is already the newest version (1.1.1f-1ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ uname -a
Linux LAPTOP-HR7UF1BP 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ env
HOME=/home/nathan
HOSTTYPE=x86_64
LANG=C.UTF-8
LOGNAME=nathan
LS_COLORS=...
NAME=LAPTOP-HR7UF1BP
PATH=/home/nathan/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Python38/Scripts/:/mnt/c/Program Files/Python38/:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/Program Files/nodejs/:/mnt/c/Program Files/CMake/bin:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/ProgramData/DockerDesktop/version-bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/Lucre/.cargo/bin:/mnt/c/Users/Lucre/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/Lucre/AppData/Roaming/npm:/mnt/c/Users/Lucre/.poetry/bin
PWD=...
SHELL=...
SHLVL=1
TERM=xterm-256color
USER=nathan
WSLENV=WT_SESSION::WT_PROFILE_ID
WSL_DISTRO_NAME=Ubuntu
WSL_INTEROP=/run/WSL/2539_interop
WT_PROFILE_ID={61c54bbd-c2c6-5271-96e7-009a87ff44bf}
WT_SESSION=30190d3e-43c0-46e3-b4d7-d3cd2d2fa688

I should be able to set the environment variables to make this work correctly, but per the instructions, I'm in a situation where I think the directory should be found automatically, so I'm filing this bug.

closed time in 16 days

Lucretiel

created tagsfackler/rust-postgres

tagpostgres-v0.17.5

Native PostgreSQL driver for the Rust programming language

created time in 16 days

release sfackler/rust-postgres

postgres-v0.17.5

released time in 16 days

push eventsfackler/rust-postgres

Steven Fackler

commit sha f6620e6a24ac416101a811b89b69cd74e137af51

Release postgres v0.17.5

view details

push time in 16 days

push eventsfackler/rust-postgres

Steven Fackler

commit sha a4a68d543ddd064da706aa5d8b3f0e856330a80b

Ensure transactions roll back immediately on drop Closes #635

view details

push time in 16 days

issue closedsfackler/rust-postgres

Transaction not rolled back on Drop if client is never used again

Hi @sfackler, thanks again for all of your work on this library!

I believe I've found a bug in the Transaction Drop implementation. Since the Tokio rewrite, the rollback that dropping an ongoing transaction is supposed to have is handled like: https://github.com/sfackler/rust-postgres/blob/4fd7527c3c88bd0c051b8d25068de0aa4956e54b/tokio-postgres/src/transaction.rs#L51-L54

Notably, the response for the rollback is not actually polled in the Drop method. The effect of this is that the rollback is not actually sent until the next time that a statement is awaited. But if no other statement is ever sent on this client, the transaction will not be rolled back. This is arguably expected when using tokio-postgres because Drop shouldn't block synchronously in an async event loop (or at least, I don't know how else that should work), but it's completely unexpected for non-async postgres.

To demonstrate, make the following changes to the transaction_drop test:

#[test]
fn transaction_drop() {
    let mut client = Client::connect("host=localhost port=5433 user=postgres", NoTls).unwrap();
    let mut client2 = Client::connect("host=localhost port=5433 user=postgres", NoTls).unwrap();

    client
        .simple_query("CREATE TABLE IF NOT EXISTS foo (id SERIAL PRIMARY KEY)")
        .unwrap();

    client
        .execute("INSERT INTO foo VALUES (1) ON CONFLICT DO NOTHING", &[])
        .unwrap();

    let mut transaction = client.transaction().unwrap();

    transaction
        .execute("SELECT * FROM foo FOR UPDATE", &[])
        .unwrap();

    drop(transaction);

    // Works if using client, blocks if using client2.
    // let rows = client.query("SELECT * FROM foo FOR UPDATE", &[]).unwrap();
    let rows = client2.query("SELECT * FROM foo FOR UPDATE", &[]).unwrap();
    assert_eq!(rows.len(), 1);
}

closed time in 16 days

nvanbenschoten
more