;ossl_uintmax_t'*
>
> *In file included from include/internal/e_os.h:17,*
>
> * from apps\include/apps.h:13,*
>
> * from apps\lib\app_libctx.c:10:*
>
> *include/openssl/crypto.h:25:21: error: stdlib.h: No such file or
> directory*
>
ponents\ip_net2-6.9\osconfig\vxworks\h
> -I$(WIND_HOME)\components\cafe-0.1\osconfig\vxworks\h -I$(TGT_DIR)\src\hwif
> -I$(TGT_DIR)\src\hwif\h -I $(TGT_DIR)\3rdparty\pbcl\h -I.
> -I$(TGT_DIR)\h\wrn\coreip -I$(TGT_DIR)\src\config
> -I$(TGT_DIR)\config\comps\src -I$(TGT_DIR)\config\comps
This error:
fatal error LNK1112: module machine type 'x64' conflicts with target
machine type 'x86'
says that you're set up for using x64 native tools, despite indicating you
have opened the x86 native tool command
Try running
vcvarsall.bat x32
Which should force your environment to build in 32
There are already several targets defined for vxworks. First step I would
think would be cloning one of those targets in Configurations/10-main.conf
for your purposes and adjusting the settings accordingly:
"vxworks-ppc60x" => {<= Change this to "vxworks-arm9' or some such
inherit
Can you post the stack trace of the segv here?
On Tue, Jul 16, 2024 at 12:43 PM Victor Wagner wrote:
> Hi!
>
> I'm using osslsigncode application on Debian 12 system (amd64) to sign
> stuff with RSA key stored on hardware token with PKCS11 interface.
>
> osslsigncode (https://github.com/mtrojnar
I've never tried, but you might try replacing /dev/random with a pipe that
reads data from an input file to make the entropy fetch deterministic.
Note that's probably dangerous, so I'd recommend doing this in a container
to isolate it from your running system
On Sat, Jul 13, 2024, 8:52 PM Syfer S
- release version (optimized)
>
>
>
> It seems they expect those file names and use them when generating a build
> system with CMake.
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company <http://www.mdsol.com/>
>
I believe the oid_file key in the config is used by the ca and req applets
and is meant to be a value rather than a section (i.e. oid_file =
/path/to/oid/file/name)
To do what I believe you are trying to do above, you need to follow the
directions here:
https://www.openssl.org/docs/man1.1.1/man5/c
You will almost certainly need to preform an nmake distclean (or just run
git clean on your tree) prior to reconfiguring. nmake is really bad about
getting lost in dependency resolution. Its quite likely that there is a
remaining object file somewhere that didn't get rebuilt for x64 when you
ran
the openssl-mac utility already contains such a option (though it doesn't
circumvent the issue as the option for the key is also passed on the
command line)
It seems some bash magic solves this problem though. By putting your key
in a file, you can use command substitution to solve this:
nhorman
I assume that, after building the openssl library you ran openssl
fipsinstall? i.e. you're not just using a previously generated
fipsmodule.cnf file? The above errors initially seem like self tests
failed on the fips provider load, suggesting that the module-mac or
install-mac is incorrect in you
code, but it seems to be. If the underlying socket is in non-blocking
mode, there should be no way for calls to block in SSL_read/SSL_write on
the socket read/write system call.
On Thu, May 23, 2024 at 8:15 AM Wiebe Cazemier wrote:
> - Original Message -
> > From: "Neil H
do you have a stack trace of the thread hung in this state? That would
confirm whats going on here
Neil
On Wed, May 22, 2024 at 11:12 PM udhayakumar
wrote:
> hi Wiebe Cazemier,
>
> The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only
> return after the handshake and successful
Glad its working a bit better for you. If you are inclined, please feel
free to open a PR with your changes for review.
Best
Neil
On Thu, May 16, 2024 at 7:40 AM Dennis Clarke wrote:
> On 5/15/24 18:34, Neil Horman wrote:
> > You are correct, the files you reference (most of the
he targets you need.
Regards
Neil
On Wed, May 15, 2024 at 4:12 PM Dennis Clarke wrote:
> On 5/13/24 03:34, Matt Caswell wrote:
> >
> >
> > On 13/05/2024 02:42, Neil Horman wrote:
> >> We added support for RCU locks in 3.3 which required the use of
> >>
We added support for RCU locks in 3.3 which required the use of atomics (or
emulated atomic where they couldn't be supported), but those were in
libcrypro not liberal
On Sun, May 12, 2024, 7:26 PM Dennis Clarke via openssl-users <
openssl-users@openssl.org> wrote:
>
> On 4/9/24 08:56, OpenSSL w
16 matches
Mail list logo
