Suggesting CRYPT_VERIFYCONTEXT | CRYPT_SILENT in place of CRYPT_VERIFYCONTEXT for each occurrence — to make sure no UI is popping up here.

Ref.: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379886.aspx

Seems like a good idea @vszakats, PR updated.

Thank you @xoloki!

RAND_screen() should go too IMO.

See also https://rt.openssl.org/Ticket/Display.html?id=2485 Probably are some other ones related.

Done @ghedo. I wasn't sure what to do with libeay.num, so I marked RAND_screen as NOEXIST. Hopefully I don't need to renumerate the entire file.

I don't have rt access @richsalz, how do I get it?

User guest password guest

Thanks @richsalz. That RT is exactly what I saw, though in my case it had the decency to crash and not deadlock. The crash appeared frequently (~66% of the time) when running my application under the VS debugger.

@xoloki RAND_event() too probably. Also, MAXDELAY and the code inside the CURSOR_SHOWING ifndef (including the comment above it) can be removed too since they seem unused. Might want to check if we actually need all the #includes as well.

Done @ghedo. I built on windows and verified that we could get rid of one #include.

The VC-WIN64A build seems a little broken in general, but I was able to build libeay32.lib so rand_win seems good.

Oh, wow, I didn't know we had a winrand app. It was added almost 16 years ago, and since then it received 4 commits in total (all of them being general code improvements, not specific to that file). Should be safe to drop as well IMO.

Done @ghedo. Nothing was even referencing winrand.c.

Also, I noticed that the debug-VC configure targets are missing in master. How do I do a debug windows build now @ghedo?

@OscarLinden, thanks for noticing. You need the following patch (to be committed soon):

diff --git a/util/mk1mf.pl b/util/mk1mf.pl
index bac5a6f..64ad29a 100755
--- a/util/mk1mf.pl
+++ b/util/mk1mf.pl
@@ -83,8 +83,6 @@ while(<IN>) {
 }
 close(IN);

-$debug = 1 if $mf_platform =~ /^debug-/;
-
 if ($mf_fipscanisterinternal eq "y") {
        $fips = 1;
        $fipscanisterbuild = 1;
@@ -1401,6 +1399,7 @@ sub read_options
                "rsaref" => 0,
                "gcc" => \$gcc,
                "debug" => \$debug,
+               "--debug" => \$debug,
                "profile" => \$profile,
                "shlib" => \$shlib,
                "dll" => \$shlib,

Thanks @levitte! I don't have a pressing need to build debug now, so I'll wait for that change to hit master.

This looks genarlly ok to me, but I'd feel happier if someone with more Windows knowledge than me took a look.
There are a number of merge commits in this PR which aren't allowed, so they need to be removed, and this PR rebased instead. Also "make update" probably needs to be run.

I did the rebase, but I couldn't push to my fork without a single merge at the end. Is this okay?

No - there can't be any merge commits. Also looks like you messed up somehow. This PR is now showing a whole load of changes which aren't yours.

I'll make a new branch and cherry pick all my actual commits.

The commits from other people showed up days ago, no idea how that happened...

@xoloki why not just do "git rebase master" from inside your branch? You might want to squash into a single commit as well.

I'm on a fork, so I did

git rebase upstream/master

From my fork's master branch.

But then I couldn't push back to my fork without an extra

git pull

Which added another merge.

Will

git rebase master

On my fork's master actually work?

Ok, new PR-1079:

#1079

On 5/16/2016 6:10 AM, mattcaswell wrote:

No - there can't be any merge commits. Also looks like you messed up
somehow. This PR is now showing a whole load of changes which aren't yours.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#512 (comment)

Replaced by #1079

@xoloki then I think you needed to just do git push --force.