ossl_decoder_fast_is_a is relatively heavy-weight

Follow-up to #20286
The code from https://gist.github.com/richsalz/31a98a3095fa36ab6a66082a0c028a6f decodes 65536 Ed25519 private keys in a loop. It makes ~153 mln iterations of ossl_decoder_fast_is_a consuming 20% of time (with descendants) - 2300 iterations per key. It looks suspicious to me.
There are several more functions called 120-160 mln times but they seem to consume 0.5-1% of time each (with descendants).
The callgrind log is attached.
callgrind.out.655458.txt

@openssl/otc a follow-up to today's meeting

The supplied code is doing a decode and an encode..
I had a look at debugging the decode part with the following c code
static const char private_header[] = {
    0x30, 0x2e,          /* SEQUENCE(3 elem) (46 bytes)     */
    0x02, 0x01, 0x00,    /*   INTEGER 0                     */
    0x30, 0x05,          /*   SEQUENCE(1 elem) (5 bytes)    */
    0x06, 0x03,          /*     OBJECT IDENTIFIER (3 bytes) */
    0x2b, 0x65, 0x6e,    /*       OBJ_X25519 -> <IP_ADDRESS> -> 1*40+3, 101, 110 */
    0x04, 0x22,          /*   OCTET STRING(1 elem) (nested) */
    0x04, 0x20           /*     OCTET STRING(32 bytes)      */
};

static int dopkcs8_decode(const unsigned char *privdata, size_t privdata_len)
{
    int ret = 0;
    unsigned char der[64];
    const unsigned char *pder = der;
    long derlen;
    PKCS8_PRIV_KEY_INFO *p8info = NULL;
    EVP_PKEY *key = NULL;
    size_t sz = sizeof(private_header);

    memcpy(der, private_header, sz);
    memcpy(der + sz, privdata, privdata_len);
    sz += privdata_len;
    derlen = sz;

    p8info = d2i_PKCS8_PRIV_KEY_INFO(NULL, &pder, derlen);
    if (p8info == NULL)
        goto err;

    key = EVP_PKCS82PKEY_ex(p8info, mainctx, NULL);
    if (key == NULL)
        goto err;
/*
  X509_PUBKEY *ppubkey = nullptr;
  if (1 != X509_PUBKEY_set(&ppubkey, key))
  {
    return nullptr;
  }

  const unsigned char *p = nullptr;
  int plen;

  if (1 != X509_PUBKEY_get0_param(nullptr, &p, &plen, nullptr, ppubkey) || !p || plen != k25519PublicKeyBytes)
  {
  }
  else
  {
  }

  X509_PUBKEY_free(ppubkey);
*/
    ret = 1;
err:
    EVP_PKEY_free(key);
    PKCS8_PRIV_KEY_INFO_free(p8info);
    return ret;
}

static int test_pkcs8_decode(void)
{
    unsigned char i, j;
    unsigned char private[32] = { 0 };

    for (i = 0; i < 1; i++) {
        private[0] = i;
        for (j = 0 ; j < 1; j++) {
            private[1] = j;
            dopkcs8_decode(private, sizeof(private));
        }
    }
    return 1;
}

I am thinking that trying to 'optimize' the decoder may be the wrong approach.
This particular code collects 18 keymanagers and 22 decoders
The 17th decoder is X25519 so that is a lot of decoders to run thru get to the right one.
It seems like decoding the blob to figure out what the decoder type, and OID is may be the best approach,
and then using that as a hint. And then falling back in the case where if the data is unknown.
What is particularly bad about this particular case is that there is a function in the legacy code that extracts the OID :)
    if (!PKCS8_pkey_get0(&algoid, NULL, NULL, NULL, p8))
        return NULL;

So couldn't it at least do that (that doesnt fix the general problem, but it addresses this one).
And use it to figure out the keytype passed to OSSL_DECODER_CTX_new_for_pkey()

@beldmit Was that a debug build for the callgrind log? (The numbers I measured in another test were quite different in release)

@slontis, when saying "It seems like decoding the blob to figure out what the decoder type, and OID is may be the best approach", I wonder in what part this should happen...

@slontis
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -ggdb -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG

I believe that on different machines the result may be different

@slontis, when saying "It seems like decoding the blob to figure out what the decoder type, and OID is may be the best approach", I wonder in what part this should happen...

I think the suggestion was to do that in EVP_PKCS82PKEY_ex prior to calling OSSL_DECODER_CTX_new_for_pkey - which helps in this very specific case.

@slontis sorry but how do those 18+22 turn into 2300 calls?

@slontis, when saying "It seems like decoding the blob to figure out what the decoder type, and OID is may be the best approach", I wonder in what part this should happen...

I think the suggestion was to do that in EVP_PKCS82PKEY_ex prior to calling OSSL_DECODER_CTX_new_for_pkey - which helps in this very specific case.

  If the OID is converted to name or canonical text form (OBJ_obj2txt() does that), we should probably be able to use that directly as the keytype, i.e. replace NULL with that in this line:
https://github.com/openssl/openssl/blob/d0a3b9d1eb1fc510ec3447b44803bbf5520a0c47/crypto/evp/evp_pkey.c#L84-L85

I'm working on it

See #20412. I ran @slontis's code (based on original code from @richsalz) but modified the loops to do 256x256 iterations as per the original. I saw these timings on my system:
1.1.1:
real	0m6.791s
user	0m6.783s
sys	0m0.009s
3.0:
real	0m47.326s
user	0m42.134s
sys	0m0.001s
3.1:
real	0m14.663s
user	0m14.658s
sys	0m0.005s
master:
real	0m15.105s
user	0m15.091s
sys	0m0.013s
master with #20412:
real	0m8.887s
user	0m8.887s
sys	0m0.000s
So the patch approximately doubles performance on master.

Obviously this is only a partial fix for the issue because it only really improves the EVP_PKCS82PKEY_ex/EVP_PKCS82PKEY functions and not decoders in general.

1.1.1 -> master with #20412 is about 30% slower. Not fantastic but significantly better than the 216% slower for 1.1.1 -> 3.1 currently or 697% for 1.1.1 -> 3.0

Nice work! I confirm 2-times speedup

callgrind.out.15039.txt
Callgrind after this patch looks much better.

I'm not sure it's realistic to speedup the whole encoder/decoder system, but there are some low-hanging fruits to cut when we find them.

See also #20416. That's still only a partial fix, but it perhaps impacts more widely than #20412.

I like @mattcaswell's approach of probing for well known formats.  We might want to think about how to do it more generically (read a block of data, try to guess type, try that/those first & fall back to what we've got now).  It needn't be perfect, just better for common cases.

A probe into a PEM file would see the first item and might provide a hint as to what it contains (or not).  A PEM file with multiple parts would be missed by the probe but picked up later in the fall back.  I.e. it shouldn't be worse unless we retry "failed" deciders.

Yeah but it still doesnt know the keytype for some of these.

Does OpenSSL ever parse multiple items in PEM format that are in a single file? Isn't that up to the application to do? (I could well be out of date here.)
Seems to me that if you have the PEM header you have a fast-path to look at the likely decoder. And you could always decode the base64 contents, and look to see if the DER agrees with the label, and raise an error if not.

Pretty sure if handles multiple items.. That would have to fallback.
-----BEGIN PRIVATE KEY------ doesnt completely help :)

Yes, generic tags would mean more work.  For example, unbase64 and look at the DER.

Pretty sure it handles multiple items.

Can you point to an API in libcrypto that does this?

Might be a question for @levitte..

Regarding PEM, the PEM functions that take a BIO or file descriptor will parse the next PEM object in that stream, so libcrypto at least supports reading multiple objects in an iterative fashion.  The OSSL_STORE API supports the same thing, obviously, but for any sort of container (not just PEM files).
It's true, though, that it's up to the application to perform the actual iteration over multiple objects in a container, generally speaking.
One might argue that OpenSSL supports reading multiple objects in one go, though, when parsing a PKCS#12 object.  You do get certs and key in one call (more or less).  But, that's not about PEM.

If I understand correctly, CAfile argument of command line utilities may contain several certificates

I think the big question here is, how to detect what chain there should be, with minimal parsing.
Like someone else already said, this is currently a bit hard to do, because we build up all the potentially viable chains before even looking at the data stream.  However, it's conceptually possible to leave that build-up until the first read of the data stream.  Simply leave it to OSSL_DECODER_CTX_new_for_pkey() just store its inputs the the resulting OSSL_DECODER_CTX, and on the first OSSL_DECODER_from_ call for that OSSL_DECODER_CTX, do some light parsing, put the resulting bytes through a process like the file command does, and use that to try to determine what a viable chain should look like.
Note that there are critical stumbling blocks with the proposed analysis.  We don't know what decoders there will be out there, so we will need to be careful about what assumptions we make.

However, it's conceptually possible to leave that build-up until the first read of the data stream. Simply leave it to OSSL_DECODER_CTX_new_for_pkey() just store its inputs the the resulting OSSL_DECODER_CTX, and on the first OSSL_DECODER_from_ call for that OSSL_DECODER_CTX, do some light parsing, put the resulting bytes through a process like the file command does (heh, does that mean we should learn to use /etc/magic?), and use that to try to determine what a viable chain should look like.

I actually did some experiments with this same idea yesterday, but I couldn't get it working properly in the time available. I do think this sounds like a potentially viable approach though.

I actually did some experiments with this same idea yesterday, but I couldn't get it working properly in the time available. I do think this sounds like a potentially viable approach though.

I'm guessing that this is mostly relevant when the input is raw DER, as such files usually contain only one object (there's one well known exception).  Since PEM files can potentially contain multiple object of all types, all you can be certain of is that it's a PEM file.

I'm guessing that this is mostly relevant when the input is raw DER,

Yes, I agree. We're mostly talking about DER here.

So we have an answer to one question: nothing in the OpenSSL libraries read more than one PEM object at a time. They only read forward to get the next one.

One might argue that OpenSSL supports reading multiple objects in one go, though, when parsing a PKCS#12 object. You do get certs and key in one call (more or less). But, that's not about PEM.

Well, there are many single-DER objects that are containers (PKCS7, OCSP response) but as you say that's not relevant here. But what did you mean by "one well-known exception?"

So we have an answer to one question: nothing in the OpenSSL libraries read more than one PEM object at a time. They only read forward to get the next one.

One might argue that OpenSSL supports reading multiple objects in one go, though, when parsing a PKCS#12 object. You do get certs and key in one call (more or less). But, that's not about PEM.

Well, there are many single-DER objects that are containers (PKCS7, OCSP response) but as you say that's not relevant here. But what did you mean by "one well-known exception?"

X509_AUX, which is a X509 DER blob directly followed by an auxilliary data blob.  This was made years (eons? :wink:) ago.
See https://github.com/openssl/openssl/blob/master/crypto/x509/x_x509a.c, and for the parsing itself, this:
https://github.com/openssl/openssl/blob/c4cb151b4d19f5f2eb302baafac65e36e4408381/crypto/x509/x_x509.c#L183-L218

Thank you, @levitte.

@mattcaswell is there more work to be done here?  It seems like you've fixed some problems, but I can't determine if there are concrete subsequent issues to address

I think mostly what remains falls into the "decoders are slow" bucket for which we have other issues (e.g. https://github.com/openssl/project/issues/100).
We might also want to consider whether the reproducer supplied here is adequately reflected in our existing performance test suite - or do we need an additional test. We have https://github.com/openssl/tools/blob/master/perf/pkeyread.c already - does this add something sufficiently new? Requires some investigation.

Ok, so I'm going to mark this as consideration for next minor release, and we can schedule that work when available


Visual/CSS problem - Component borders not visible in Canvas App

Component borders are not visible in Canvas Apps unless a value has been entered, making the control semi-invisible until a value has been added.

Fixed this error by adding a colour based border.


typescript+webpack template presents a blank app window when debugging in vscode under Windows 10

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
6.0.0-beta.63
Electron version
v16.0.7
Operating system
Windows 10
Last known working Electron Forge version
unknown
Expected behavior
Electron app starts and renders as it normally would if running '.\node_modules.bin\electron-forge start' from the command line.
Actual behavior
Electron app present a blank window.
Steps to reproduce

Create the application using the typescript+webpack template.
Open the application folder using vscode (using vscode version 1.63.2 in this case).
Create a debugging launch profile as per Debugging with VS Code.
Launch the debugger through vscode.

Additional information
After much trial and error, found that removing the fork-ts-checker-webpack-plugin plugin resolves the issue. Tried the latest fork-ts-checker-webpack-plugin (6.5.0) and ts-loader (9.2.6) npm packages to no avail.
Have been using it under Linux for a while now and have never had this issue. When I tried building and debugging my actual application, which is originally based off the typescript+webpack template, under Windows 10 I discovered this issue, and troubleshooting led me to pulling it apart and stripping it down.
Unsure whether this is an integration issue with electron-forge/fork-ts-checker-webpack-plugin, or an issue with the fork-ts-checker-webpack-plugin itself.
Would welcome a better workaround than removing fork-ts-checker-webpack-plugin if anyone knows what the actual issue is.

Same issue on Windows

Also experienced this in Windows 10 using the typescript+weback template

Minimal repro for this, created with npx create-electron-app ... --template=typescript-webpack
https://github.com/RandomEngy/electron-forge-webpack-ts-debugging

I can confirm, that removing 'fork-ts-checker-webpack-plugin' solves issue. Any idea why ? There is no error in log / debug messages.

Having the exact same behavior here.

FYI here I show the launch.json file I use for debugging:

https://github.com/electron/forge/issues/2789#issuecomment-1320963413


lengthy links truncate on social media websites

Problem: An effective way to reduce impact of this virus is to communicate best practices faster than the virus infects. Therefore working short links are critical.
When clicking on "Create shareable link" I'd copy (for example) https://aatishb.com/covidtrends/?location=Hong+Kong&location=Italy&location=Singapore&location=Spain&location=Taiwan
Now when pasting on certain websites, specifically facebook, once posted the clickable link results in : https://aatishb.com/covidtrends/?location=Hong+Kong with the rest truncated.
This issue highlights two problems. lengthy links and two the links truncate
This makes it more difficult to communicate quickly when discussing different strategies and the efficacy thereof.
Potential Solution: ideally the link is short thus doesn't demand a lot of space in tweets and cluttering communications. I know you can use a url shortener, but I personally hate those and will very rarely click on them.

Hmm as of now I feel like this is a facebook bug/issue if they are breaking long URLs. Not sure we should make our URLs more cryptic for this. Willing to reconsider if there's any easy solution that retains URL transparency (i.e. not a link shortener).

@aatishb one way to alleviate this situation would be to use country/region codes, such as ISO 3166 or US state abbreviations.
So the link above would become:
https://aatishb.com/covidtrends/?location=HK&location=IT&location=SG&location=ES&location=TW.
You could also shorten the parameter names, e.g. location → loc (or even l, though I agree that would be too cryptic). The result would be:
https://aatishb.com/covidtrends/?loc=HK&loc=IT&loc=SG&loc=ES&loc=TW.

https://aatishb.com/covidtrends/?loc=hk+it+sg+es+tw
The above is shorter and not obscure. It also works on facebook.

Thanks. This is helpful feedback. I like the simplified format @sjmackenzie suggests. If we go this route, we'll need a list of unique abbreviations for every subregion on our selectors. We'd probably also need to pull country codes from JHU, which is not straightforward but apparently doable. And we should try not to break existing URLs.

Overall I feel this is an interesting idea and it will take a fair bit of work to get it right. I've been avoiding dealing with ISO codes so far because the data doesn't already directly include them. We may eventually need to deal with this. I'm not prioritizing this highly for now as there are so many other areas we can improve as well, but I'm open to thinking more about how to implement this.

I've edited my previous comment to locs instead of loc so that existing links are not broken.
A possible route is to apply a data transformation on import. Thus the data directly includes ISO codes. The data transformation step should use this lookup table  which is part of the data source.

FYI, that table seems to only use national-level (ISO 3166-1) codes, so the subnational regions appear to share the same iso2/iso3 codes (ISO 3166-1 alpha-2 and ISO 3166-1 alpha-3, to be exact), even though they are differentiable by ISO 3166-2. For example, the various regions of China all use CN/CHN, but say, Hubei does has a unique code, CN-HB. So we'd need to augment that table with the subdivision data (e.g. here's one)

How about something a bit more dirty, but far simpler:
https://aatishb.com/covidtrends/?locs=344+380+702+724+158+15613
UID: 344 hong kong
UID: 380 italy
UID: 702 singapore
UID: 724 spain
UID: 158 taiwan
UID: 15613 hubei

This allows us to compare states/provinces/countries against other states/provinces/countries.
IMHO I don't really care about an intelligible links, just a short (enough) link that works on every platform enabling conversations on strategies. It would be good to have something that doesn't mess with the data too much.

I think it's quite doable to host a full look-up table in this repo, based on the ones linked above. It only needs to be done once, and it's not a lot of work either since most of the content can be generated automatically. I'm willing to contribute such a table if this is the approach that we decide to move ahead with.
On a separate work, the short URL (using a single locs parameter) would probably be more readable with commas instead of a plus sign, especially since some of the codes may have dashes in them:
https://aatishb.com/covidtrends/?locs=hk,it,sg,es,tw

(It also looks more like a list, which is another plus.)

This looks great to me, though probably best to test whatever chosen separator character on facebook twitter and other big ones. I assume you want ISO 3166-2?

I'm in favor of shortening the lengthy links (in a way that doesn't break existing behavior). The location URL was a hastily added feature the first time around, so I agree it's a good idea to revisit and do it right.
My concern with a manual lookup table is that it will break if JHU changes how they name countries. Perhaps they are not still doing this, but a while back the country names were changing regularly. Also do they update their lookup table when they add a new country to the dataset? Or is it already comprehensive?
Is there some standard for what separator we should use in these kinds of URL strings (+ or ,)?

Since I recently dealt with the whole URL stuff, might as well give my two cents here.
Quick summary:

Facebook only uses the last location, everything else seems fine.

Would like to know other (specific) sites that break

Like ?locs=hk,it,sg,es,tw idea
No standard regarding separators (as long as special characters aren't used)

From the top, the truncated links issue. Having only Facebook to test (as that was the only site specifically mentioned), I can indeed confirm and replicate partially what happens. Pasting a queried URL and then posting it yields the following results:

Original link: https://aatishb.com/covidtrends/?location=Australia&location=Brazil&location=Canada&location=China&location=France&location=Germany&location=Hong+Kong&location=India&location=Italy&location=Japan&location=Portugal&location=Russia&location=Singapore&location=South+Korea&location=Spain&location=Taiwan&location=Turkey&location=US&location=United+Kingdom
Facebook link: (facebook link domain stuff) https://aatishb.com/covidtrends/?location=United+Kingdom&fbclid=(some_random_string)

Trying out other regions (e.g. Canada) I end up finding that the main issue is that Facebook only detects the last location parameter present. I think this is an issue with Facebook's scrapper, as checking the page with their tools shows that it just doesn't look for the exact address given.
As far as I know, having multiple parameters with the same key isn't forbidden, and tools such as Python's urllib.parse and even URLSearchParams seem to have means of reporting every parameter. I might raise a bug with Facebook about this, given time.
There's also another issue in that long links are ellipsed, making it even harder for someone to check the actual URL.
I would also like to know what other (specific) sites are truncating links like this or if this is just a Facebook issue. Granted, Facebook is where most people end sharing stuff, so this needs to be looked into regardless.
As for shorter links, I'm perfectly fine with all the suggestions given, being more partial to @waldyrious latest idea. I don't enjoy having numeric country codes (as @sjmackenzie suggested) as they aren't as clear and make understanding the URL at a glance harder, although if the JHU data doesn't change the countries' names/UIDs, it would be the easiest to do.
From what I checked, there isn't a consistent standard regarding the separators (as long as reserved characters aren't used). I would support using regular commas, as plus signs are the URL encoding of spaces, though it's pretty much the same, I guess.
(On the current URL scheme) Replacing the & with ; could work (as Facebook doesn't seem to complain), but it isn't very usual nowadays (Python seems to understand they are different parameters, but JS not).
From what I understand, this is mostly a maintenance issue: having to check whether JHU breaks whatever convention they set up (if we use our own lookup table, or they don't update theirs) and supporting older links.


incomingCall' listener not working . Getting error "Callingcommunicatoirerror at callAgentImpl.on" when using callAgent.on('incomingCall', handleIncomingCall) in reactjs

No incoming event getting called when a remote participants join the call or exit from the call.
I have used the below code in App.js
const { token, user } = await fetchTokenResponse();
const tokenCredential = new AzureCommunicationTokenCredential(token);
const callClient = new CallClient();
const callAgent = await callClient.createCallAgent(tokenCredential);

callAgent.on('incomingCall', (incomingCallEvent) => {

      console.log('Incoming call event:', incomingCallEvent);

  });

Same issue here.

Hi @ramkrishnasamanta8, incomingCall is used for listening to new calls where your ACS client has been directly called by another client.
For getting events when a user joins or leaves a specific call use the call.on('remoteParticipantsUpdated') event.

Closing this issue due to inactivity. Please feel free to re-open if you have any additional questions.


Test discovery is not working when default processor architecture set to x64

In Visual Studio 2013. (node.js x64)
Tests cannot be discovered or displayed in grey after this settings is applied:
Test->Test Settings -> Default Processor Architecture -> x64

I was facing a similar issue, where I had another test adapter that was causing the vstest.discoveryengine.exe to run (instead of vstest.discoveryengine.x86.exe) and this resulted in the tests not being discovered.  However, I found the following work around.
First, download the source code, and recompile the TestAdapter project with 'Any CPU' as the target platform. Then, replace the test adapter dll in the install directory with the dll that was generated from this compilation and re-open Visual Studio.

@lukedgr Indeed that works! Just verified we don't have any 32-bit-required dependencies in the project and submitted a PR.

Fixed in #111

Available in the latest dev build

NTVS 1.0 - Mar 25, 2015 - Where not seeing any tests get picked up, regardless of configuration, on VS 2015 RC.
5-13-2015 Dev Build - Confirmed resolved for all architectures.
Thanks!
Todd


Travel

Allow user to buy a plane, that gives them access to "the skies", which is an ascii map where users can click on places around the globe and travel there. Traveling to a new place makes different maps available in "the streets"

basic functionality in place db50fec9748a9492ed433e3048d4b8e7d8be405d

probably good enough for now


fix: source certificates into Gatsby

This makes it possible to get the certificate information via graphQL query instead of direct filesystem searches or needing to recreate it inside /client.

Thanks for this Oliver. However, we should probably make the same filter for the client/src/components/landing/index.js. Unless we want this:

Good catch, Shaun. I'll sort that out.

@Sky020 with the latest changes certificates never become ChallengeNodes and are turned into CertificateNodes instead.  This slightly simplifies the queries (no need to filter).
Let me know if this works for you and I'll clean up the commits.

Not a good reason, no.  I'll fix it.

@ojeytonwilliams I was expecting the original test to be removed, unless there is a reason to have the extra redundancy?

It's not actually redundancy.  The specific tests confirm the presence of the certs we expect to be there.  The original test confirms that there are only 10.  We need both to be sure that we have what we want and nothing else.


switch from travis to GitHub Actions

Plans add  NPM_TOKEN to
Settings / Secrets so that nom publish can be executed form within GitHub Actions

Repository secrets
NPM_TOKEN
Updated on 30 Jul


Todo: View raw message context command

Going to drop this one from todo since Discord added a "Copy Text" button to desktop which achieves the same function (it copies the raw text).


Fix memory leaks in code

Leak analysis with Google address sanitizer revealed no. of memory leaks, likely responsible for the double corruption/free() errors we see in some of the tasks.
Compiling with:    -fsanitize=address -ggdb3
produced following leak report:
=================================================================
==801==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8448 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46666375 in __GI___regcomp /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:472

Direct leak of 7392 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cadc3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x7fca46665934 in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:750

Direct leak of 4995 byte(s) in 65 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46afba53 in get_option zip/z_fileio.c:4759

Direct leak of 2550 byte(s) in 10 object(s) allocated from:
    #0 0x7fca46cada06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fca46adb6ee in boinc_zip(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const*) (/home/glenn/github/boinc-install/lib/libboinc_zip.so.7+0x116ee)

Direct leak of 680 byte(s) in 5 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46afaaed in copy_args zip/z_fileio.c:3789

Direct leak of 512 byte(s) in 1 object(s) allocated from:
    #0 0x7fca46caf787 in operator new[](unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cc:107
    #1 0x56294c91148b in process_trickle(double, char const*, char const*, char const*, int) /home/glenn/github/cpdn-openifs/openifs.cpp:1366
    #2 0x56294c907ffa in main /home/glenn/github/cpdn-openifs/openifs.cpp:1133
    #3 0x7fca4658b082 in __libc_start_main ../csu/libc-start.c:308

Indirect leak of 28672 byte(s) in 14 object(s) allocated from:
    #0 0x7fca46cada06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fca4665bd04 in build_trtable /build/glibc-SzIz7B/glibc-2.31/posix/regexec.c:3403
    #2 0x7fca4665f44f in transit_state /build/glibc-SzIz7B/glibc-2.31/posix/regexec.c:2252
    #3 0x7fca4665f44f in check_matching /build/glibc-SzIz7B/glibc-2.31/posix/regexec.c:1120
    #4 0x7fca4665f44f in re_search_internal /build/glibc-SzIz7B/glibc-2.31/posix/regexec.c:792

Indirect leak of 8624 byte(s) in 98 object(s) allocated from:
    #0 0x7fca46cada06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fca4665ac13 in create_cd_newstate /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1678
    #2 0x7fca4665ac13 in re_acquire_state_context /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1553

Indirect leak of 5490 byte(s) in 80 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46afab23 in copy_args zip/z_fileio.c:3799

Indirect leak of 3200 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cada06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fca466644f8 in init_dfa /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:866
    #2 0x7fca466644f8 in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:758

Indirect leak of 2944 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca466649eb in analyze /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1172
    #2 0x7fca466649eb in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:795

Indirect leak of 2944 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca466649db in analyze /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1171
    #2 0x7fca466649db in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:795

Indirect leak of 2944 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca466644c1 in init_dfa /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:859
    #2 0x7fca466644c1 in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:758

Indirect leak of 1568 byte(s) in 98 object(s) allocated from:
    #0 0x7fca46cadc3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x7fca46653a43 in register_state /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1589

Indirect leak of 1088 byte(s) in 68 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca4665ae88 in create_cd_newstate /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1713
    #2 0x7fca4665ae88 in re_acquire_state_context /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1553

Indirect leak of 736 byte(s) in 33 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca466649ba in analyze /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1169
    #2 0x7fca466649ba in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:795

Indirect leak of 664 byte(s) in 98 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca4665ac4f in re_node_set_init_copy /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1033
    #2 0x7fca4665ac4f in create_cd_newstate /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1681
    #3 0x7fca4665ac4f in re_acquire_state_context /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1553

Indirect leak of 544 byte(s) in 68 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca4665aed3 in re_node_set_init_copy /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1033
    #2 0x7fca4665aed3 in create_cd_newstate /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1720
    #3 0x7fca4665aed3 in re_acquire_state_context /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1553

Indirect leak of 544 byte(s) in 17 object(s) allocated from:
    #0 0x7fca46cada06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fca46660f6e in parse_bracket_exp /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:3122
    #2 0x7fca46660f6e in parse_expression /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:2288

Indirect leak of 468 byte(s) in 100 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46658ae9 in re_node_set_alloc /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:972
    #2 0x7fca46658ae9 in calc_eclosure_iter /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1700

Indirect leak of 426 byte(s) in 98 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca46653952 in re_node_set_alloc /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:972
    #2 0x7fca46653952 in register_state /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:1574

Indirect leak of 68 byte(s) in 17 object(s) allocated from:
    #0 0x7fca46cad808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7fca4666510a in re_node_set_init_1 /build/glibc-SzIz7B/glibc-2.31/posix/regex_internal.c:985
    #2 0x7fca4666510a in link_nfa_nodes /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1464
    #3 0x7fca4666510a in preorder /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1265
    #4 0x7fca4666510a in analyze /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:1201
    #5 0x7fca4666510a in re_compile_internal /build/glibc-SzIz7B/glibc-2.31/posix/regcomp.c:795

SUMMARY: AddressSanitizer: 85501 byte(s) leaked in 1068 allocation(s).

Relates to #11.

Leaks from boinc_zip().
It's clear from the trace there's alot of leaks from the use of boinc_zip.
Checked the calls and found that several calls to boinc_zip were not using the right type, the upload filepath was passed as a char [ ] rather than std::string as defined in the header.  Although this works, it means the compiler will do a copy into a string. It's possible this might be causing memory leaks further down the calling tree.
Have changed:
 retval = boinc_zip(ZIP_IT,upload_file,&zfl);
to
std::string upfile("");
...
 upfile = string(upload_file);
retval = boinc_zip(ZIP_IT,upfile,&zfl);  // n.b. pass std::string to avoid copy-on-call
upfile.clear();

This works ok but still seeing leaks reported by Asan.
If I add a 'return 1' directly after the very first call to boinc_zip() for unzipping the app zipfile then I get the first leak:
=================================================================
==1552==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 255 byte(s) in 1 object(s) allocated from:
    #0 0x7fd6a6b5ea06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7fd6a698c6ee in boinc_zip(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const*) (/home/glenn/github/boinc-install/lib/libboinc_zip.so.7+0x116ee)

SUMMARY: AddressSanitizer: 255 byte(s) leaked in 1 allocation(s).

255 bytes suggests a possible pointer being lost?  Tried a couple of things but was unable to get around this leak in the controller code.
Am not sure if the problem is with the way the control code is calling the function boinc_zip() or with boinc_zip itself. It will take more work to determine this.
Will split this issue and create separate one for boinc_zip() and look at it later, after CPDN have assessed the reduction in memory errors from these changes.

Current crop of leaks is fixed - leaks in boinc_zip split into new issue.


navigator variable access not protected (undefined during SSR)

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report
[ ] Performance issue
[X] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior
Currently in utils.ts the navigator variable access is not protected against being undefined (for example during SSR with Gatsby)
Expected behavior
If navigator variable does not exist, just return isMac = false
What is the motivation / use case for changing the behavior?
Support SSR rendering
Environment

Libs:
- react version: 17.x.x
- reakeys version: 1.2.9

Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
- [ X ] SSR

For Tooling issues:
- Node version: XX
- Platform:

Others:

I've encountered this warning also. I assume its not a problem, it doesn't seem to be.
It would be good to have less verbose console output. The below is repeated many times when i build the site:
ReferenceError: navigator is not defined
    at file:///Users/john/Projects/blog/node_modules/reakeys/dist/index.js:95:3
    at ModuleJob.run (node:internal/modules/esm/module_job:192:25)
    at async DefaultModuleLoader.import (node:internal/modules/esm/loader:228:24)
    at async importModuleDynamicallyWrapper (node:internal/vm/module:428:15)

This is caused by mousetrap. We are going to move off of it since its not updated recently.


Show parsed value after passing it to Zod

Sometimes it's important to remove unexpected fields or to check what the values are after transformations.
To ensure the correct behaviour, being able to see the parsed value would be amazing.

Okay nevermind, I found how to do it :D

Then maybe take this as a feedback to make it more obvious how to get the parsed data? 🤔

Hey @IchordeDionysos, thank you for your feedback. You can see the parsed data also in the right panel, which you can activate with that button.

However, I agree with you. We should find a more intuitive way to show the parsed data.

Ahh got it! That's a nice panel.
Maybe we could make the panel by default expanded or change the icon maybe something like:

Given there are two columns and the icon indicates a two-column icon I thought it was to collapse the value column 🤔


⚠ Bofrost.be has degraded performance

In e26daf3, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1461 ms

Resolved: Bofrost.be performance has improved in f600de4 after 6 minutes.


React Final Form callbacks are incompatible with date components

The event callbacks from the FieldInputProps of React Final Form library are supposed to work with event targets of HTMLElement subtypes. By default all the date components expect event callbacks with targets of Element subtypes, which is more general. Therefore, we can't use the input callbacks out of box like this:
<Field ...>
    {({input}) => (
        <DatePicker onFocus={input.onFocus} ... />
    )}
</Field>

We have to wrap the callbacks instead:
const handleFocus = useCallback<Required<DatePickerProps>['onFocus']>(
    (event) => {
        if (event.target instanceof HTMLElement) {
            input.onFocus(event as React.FocusEvent<HTMLElement>);
        }
    },
    [onBlur],
);

It seems unnecessary, since the date components are supposed to work using HTML elements, I believe.

fixed in #54


alternative labels part_of and has_participant

From<EMAIL_ADDRESS>on June 27, 2012 14:15:36
Melanie is worried about the disappearance of part_of and has_participant from the spec and impact on users. Alan suggests to give the "part of at all times" the label "part of" and "has participant at some time" the label "has
participant".
see https://groups.google.com/forum/?fromgroups#!topic/bfo-owl-devel/k7KkoOn6DY0
Original issue: http://code.google.com/p/bfo/issues/detail?id=71

From<EMAIL_ADDRESS>on June 28, 2012 15:22:35
> Alan suggests to give the "part of at all times" the label "part of" and "has participant at some time" the label "has participant"."
I think this is a good solution.

From<EMAIL_ADDRESS>on June 29, 2012 13:31:32
After discussion at meeting of 2012-06-29 we decided to close this issue. We don't want to make the change now because it is unclear whether the assumptions of the old relation will carry to the new relations - there are four candidates for part-of (c,o x all/some times). So we will document this in the release notes and take it up again after we get wider comment from the community.
Status: WontFix


Make sure file mode of /dev/pts/ptmx is 0666

This is required for running commands likes screen and tmux, especially inside containers.
See also : https://www.kernel.org/doc/Documentation/filesystems/devpts.txt
Motivation for this change
Currently, when creating a container, the pts filesystem is mounted without the right permission. As a result, tmux fails to create a new session. According to the kernel doc, it should be mounted with mode 0666.
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Awesome! I was wondering why terminal multiplexers weren't working in containers for users != root. Thanks!:beers:


Updated OWNERS file for release-2.7

https://issues.redhat.com/browse/ACM-2363
Signed-off-by: dislbenn<EMAIL_ADDRESS>

/retest

/lgtm

/retest


Fix small typo in README.md

Hi,
I'm having a look at the library to evaluate its integration in my projects. It looks brilliant :-) just found this small typo and wanted to fix it

Thanks :)


Use input() in nltk.chat.chatbot() for Jupyter support

Fixes #3021
Hello!
Pull request overview

Replace sys.stdin.readline() with input() in nltk.chat.chatbot()

Details
The following snippet is used to let users pick which of the 5 NLTK chatbots should be instantiated:
https://github.com/nltk/nltk/blob/1f28903066fe3ee3a4ab75085bfd5254184d135c/nltk/chat/__init__.py#L43-L44
However, the sys.stdin.readline() constantly triggers in such a way that choice is an empty string. This causes an endless loop, exactly as described in #3021:

Note that this is the output directly after running the cell. Be warned when testing this, this ended up crashing my computer due to the endless loop.

Changes
This PR simply updates this somewhat outdated form of getting user input by using the better supported input(). Running the cell now results in:

After which the chatbot works like intended & expected.
Thank you @jmcelroy01 for raising this issue.

Tom Aarsen

Thanks @tomaarsen


installer: Add missing error check

Refs #2666 (this should fix the issue, or at least return a meaningful error).

LGTM