Debian oval does not seems to be parsed correctly

What did you do? (required. The issue will be closed when not provided.)
Trying to use server mode with a payload with (fixed) openssl versions returns list of CVE that are fixed for months
What did you expect to happen?
Oval matching should only return CVE not fixed by distribution
Steps to reproduce the behaviour
With the following payload:
{
  "family": "debian",
  "version": "9.13",
  "release": "9.13",
  "runningKernel": {
    "release": "4.9.0-17-amd64",
    "version": "17"
  },
  "packages": {
    "openssl": {
      "name": "openssl",
      "version": "1.0.1t-1+deb8u8",
      "deb_status": "ii",
      "binaryNames": [
        "libssl1.0.0:amd64",
        "libssl1.1:amd64"
      ]
    }
  }
}

The following command :
curl -X POST -H "Content-Type: application/json" --data-binary @log https://vuls.endpoint

Returns the following content (truncated):
     "CVE-2016-2842": {
        "cveID": "CVE-2016-2842",
        "confidences": [
          {
            "score": 100,
            "detectionMethod": "OvalMatch"
          }
        ],
        "affectedPackages": [
          {
            "name": "openssl",
            "fixedIn": "1.0.2g-1"
          }
        ],
        "cveContents": {
          "debian": [
            {
              "type": "debian",
              "cveID": "CVE-2016-2842",
              "title": "CVE-2016-2842 openssl",
              "summary": "The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.",
              "cvss2Score": 0,
              "cvss2Vector": "",
              "cvss2Severity": "",
              "cvss3Score": 0,
              "cvss3Vector": "",
              "cvss3Severity": "",
              "sourceLink": "https://security-tracker.debian.org/tracker/CVE-2016-2842",
              "references": [
                {
                  "link": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2842",
                  "source": "CVE",
                  "refID": "CVE-2016-2842"
                }
              ],
              "published": "0001-01-01T00:00:00Z",
              "lastModified": "0001-01-01T00:00:00Z"
            }
          ],
          "nvd": [
            {
              "type": "nvd",
              "cveID": "CVE-2016-2842",
[...]

However, as per https://security-tracker.debian.org/tracker/CVE-2016-2842 the issue has been fixed in 1.1.0l-1~deb9u4 for debian stretch.
Note: We are currently using some not-released code to include #176  . Our current versions (docker based) are:

vuls : v0.19.0
cvedict : v0.8.1
goval-dict : latest (updated 3 days ago, so to be exact :

    Image ID:      docker-pullable://vuls/goval-dictionary@sha256:d566ee00d3ef984ed56df025518138176e75cb128ed44536da57215ba524add1

It looks like we did not have these false reports until a few days ago (so might be related to the update to d566ee0 version).

@maxenced
I just looked it up and this is how it is defined.(2021/12/24 9:31 JST)
This is how it is defined in OVAL(https://www.debian.org/security/oval/oval-definitions-stretch.xml).
<definition class="vulnerability" id="oval:org.debian:def:230480040338778212221740168788749474401" version="1">
  <metadata>
    <title>CVE-2016-2842 openssl</title>
    <affected family="unix">
      <platform>Debian GNU/Linux 9</platform>
      <product>openssl</product>
    </affected>
    <reference ref_id="CVE-2016-2842" ref_url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2842" source="CVE"/>
    <description>The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.</description>
    <debian>
      <moreinfo></moreinfo>
    </debian>
  </metadata>
  <criteria comment="Release section" operator="AND">
    <criterion comment="Debian 9 is installed" test_ref="oval:org.debian.oval:tst:1"/>
    <criteria comment="Architecture section" operator="OR">
      <criteria comment="Architecture independent section" operator="AND">
        <criterion comment="all architecture" test_ref="oval:org.debian.oval:tst:2"/>
        <criterion comment="openssl DPKG is earlier than 1.0.2g-1" test_ref="oval:org.debian.oval:tst:11366"/>
      </criteria>
    </criteria>
  </criteria>
</definition>

It is also defined in gost (Debian Security Tracker: https://security-tracker.debian.org/tracker/data/json) as such.
"CVE-2016-2842": {
    "description": "The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.",
    "scope": "local",
    "releases": {
      "bookworm": {
        "status": "resolved",
        "repositories": { "bookworm": "1.1.1l-1" },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "bullseye": {
        "status": "resolved",
        "repositories": {
          "bullseye": "1.1.1k-1+deb11u1",
          "bullseye-security": "1.1.1k-1+deb11u1"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "buster": {
        "status": "resolved",
        "repositories": {
          "buster": "1.1.1d-0+deb10u7",
          "buster-security": "1.1.1d-0+deb10u7"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "sid": {
        "status": "resolved",
        "repositories": { "sid": "1.1.1l-1" },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "stretch": {
        "status": "resolved",
        "repositories": {
          "stretch": "1.1.0l-1~deb9u1",
          "stretch-security": "1.1.0l-1~deb9u4"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      }
    }
},

Based on this information, this result appears to be correct. (That is, the parse is done correctly.)

I prepared the environment for openssl(1.1.0l-1~deb9u4).
root@6f7d3717819a:/# dpkg -l | grep openssl
ii  openssl                    1.1.0l-1~deb9u4                   amd64        Secure Sockets Layer toolkit - cryptographic utility

Let's try to scan and report on the prepared environment.
In this environment, CVE-2016-2842 could not be detected.
$ vuls scan vuls-target && $ vuls report
[Dec 24 10:02:45]  INFO [localhost] vuls-v0.19.0-build-20211224_095459_2b7294a
[Dec 24 10:02:45]  INFO [localhost] Start scanning
[Dec 24 10:02:45]  INFO [localhost] config: /home/mainek00n/github/github.com/MaineK00n/vuls/config.toml
[Dec 24 10:02:45]  INFO [localhost] Validating config...
[Dec 24 10:02:45]  INFO [localhost] Detecting Server/Container OS...
[Dec 24 10:02:45]  INFO [localhost] Detecting OS of servers...
[Dec 24 10:02:45]  INFO [localhost] (1/1) Detected: vuls-target: debian 9.13
[Dec 24 10:02:45]  INFO [localhost] Detecting OS of containers...
[Dec 24 10:02:45]  INFO [localhost] Checking Scan Modes...
[Dec 24 10:02:45]  INFO [localhost] Detecting Platforms...
[Dec 24 10:02:46]  INFO [localhost] (1/1) vuls-target is running on other
[Dec 24 10:02:46]  INFO [vuls-target] Scanning OS pkg in fast mode

Scan Summary
================
vuls-target	debian9.13	200 installed

To view the detail, vuls tui is useful.
To send a report, run vuls report -h.
[Dec 24 10:02:46]  INFO [localhost] vuls-v0.19.0-build-20211224_095459_2b7294a
[Dec 24 10:02:46]  INFO [localhost] Validating config...
[Dec 24 10:02:46]  INFO [localhost] cveDict.type=sqlite3, cveDict.url=, cveDict.SQLite3Path=/usr/share/vuls-data/cve.sqlite3
[Dec 24 10:02:46]  INFO [localhost] ovalDict.type=sqlite3, ovalDict.url=, ovalDict.SQLite3Path=/usr/share/vuls-data/oval.sqlite3
[Dec 24 10:02:46]  INFO [localhost] gost.type=sqlite3, gost.url=, gost.SQLite3Path=/usr/share/vuls-data/gost.sqlite3
[Dec 24 10:02:46]  INFO [localhost] exploit.type=sqlite3, exploit.url=, exploit.SQLite3Path=/usr/share/vuls-data/go-exploitdb.sqlite3
[Dec 24 10:02:46]  INFO [localhost] metasploit.type=sqlite3, metasploit.url=, metasploit.SQLite3Path=/usr/share/vuls-data/go-msfdb.sqlite3
[Dec 24 10:02:46]  INFO [localhost] kevuln.type=sqlite3, kevuln.url=, kevuln.SQLite3Path=/usr/share/vuls-data/go-kev.sqlite3
[Dec 24 10:02:46]  INFO [localhost] Loaded: /home/mainek00n/github/github.com/MaineK00n/vuls/results/2021-12-24T10:02:46+09:00
[Dec 24 10:02:46]  INFO [localhost] OVAL debian 9.13 found. defs: 25175
[Dec 24 10:02:46]  INFO [localhost] OVAL debian 9.13 is fresh. lastModified: 2021-12-24T10:02:01+09:00
[Dec 24 10:02:47]  INFO [localhost] vuls-target: 0 CVEs are detected with OVAL
[Dec 24 10:02:48]  INFO [localhost] vuls-target: 284 CVEs are detected with gost
[Dec 24 10:02:48]  INFO [localhost] vuls-target: 0 CVEs are detected with CPE
[Dec 24 10:02:51]  INFO [localhost] vuls-target: 6 PoC are detected
[Dec 24 10:02:51]  INFO [localhost] vuls-target: 1 exploits are detected
[Dec 24 10:02:51]  INFO [localhost] vuls-target: total 284 CVEs detected
[Dec 24 10:02:51]  INFO [localhost] vuls-target: 0 CVEs filtered by --confidence-over=80
vuls-target (debian9.13)
========================
Total: 284 (Critical:17 High:100 Medium:127 Low:16 ?:24)
0/284 Fixed, 82 poc, 1 exploits, cisa: 0, uscert: 4, jpcert: 3 alerts
200 installed

+---------------------+------+--------+-----+-----------+---------+---------------------------------------------------+
|       CVE-ID        | CVSS | ATTACK | POC |   ALERT   |  FIXED  |                        NVD                        |
+---------------------+------+--------+-----+-----------+---------+---------------------------------------------------+
| CVE-2016-1585       |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-1585    |
| CVE-2017-1000082    |  9.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-1000082 |
| CVE-2017-11462      |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-11462   |
| CVE-2017-12762      |  9.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-12762   |
| CVE-2017-15088      |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-15088   |
| CVE-2018-6485       |  9.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-6485    |
| CVE-2018-6551       |  9.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-6551    |
| CVE-2019-1010022    |  9.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-1010022 |
| CVE-2019-12900      |  9.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12900   |
| CVE-2019-18276      |  9.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-18276   |
| CVE-2019-8457       |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-8457    |
| CVE-2019-9169       |  9.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9169    |
| CVE-2019-9893       |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9893    |
| CVE-2020-11656      |  9.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-11656   |
| CVE-2021-27219      |  9.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-27219   |
| CVE-2021-33574      |  9.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-33574   |
| CVE-2021-35942      |  9.1 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-35942   |
| CVE-2017-17522      |  8.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-17522   |
| CVE-2017-5130       |  8.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-5130    |
| CVE-2018-1000858    |  8.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-1000858 |
| CVE-2019-1010023    |  8.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-1010023 |
| CVE-2019-17594      |  8.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-17594   |
| CVE-2019-8905       |  8.8 |  AV:A  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-8905    |
| CVE-2019-8907       |  8.8 |  AV:A  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-8907    |
| CVE-2020-26559      |  8.8 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26559   |
| CVE-2021-39537      |  8.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-39537   |
| CVE-2016-2779       |  8.6 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-2779    |
| CVE-2016-2781       |  8.6 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-2781    |
| CVE-2021-32078      |  8.4 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-32078   |
| CVE-2018-12886      |  8.1 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-12886   |
| CVE-2019-13627      |  8.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-13627   |
| CVE-2019-17543      |  8.1 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-17543   |
| CVE-2020-26560      |  8.1 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26560   |
| CVE-2020-6096       |  8.1 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-6096    |
| CVE-2021-3506       |  8.1 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3506    |
| CVE-2021-38300      |  8.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-38300   |
| CVE-2013-7445       |  7.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2013-7445    |
| CVE-2016-9318       |  7.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-9318    |
| CVE-2017-15131      |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-15131   |
| CVE-2017-18078      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-18078   |
| CVE-2017-7245       |  7.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-7245    |
| CVE-2017-7246       |  7.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-7246    |
| CVE-2017-9986       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-9986    |
| CVE-2018-1000001    |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-1000001 |
| CVE-2018-12930      |  7.8 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-12930   |
| CVE-2018-12931      |  7.8 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-12931   |
| CVE-2018-20669      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-20669   |
| CVE-2018-25020      |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-25020   |
| CVE-2018-6954       |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-6954    |
| CVE-2019-0145       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-0145    |
| CVE-2019-12456      |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12456   |
| CVE-2019-19377      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19377   |
| CVE-2019-19378      |  7.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19378   |
| CVE-2019-19449      |  7.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19449   |
| CVE-2019-19814      |  7.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19814   |
| CVE-2019-19882      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19882   |
| CVE-2019-3843       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-3843    |
| CVE-2019-3844       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-3844    |
| CVE-2019-6488       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-6488    |
| CVE-2020-11725      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-11725   |
| CVE-2020-12362      |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-12362   |
| CVE-2020-15778      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-15778   |
| CVE-2020-16156      |  7.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-16156   |
| CVE-2020-1712       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-1712    |
| CVE-2020-35457      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-35457   |
| CVE-2020-36385      |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-36385   |
| CVE-2021-0929       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-0929    |
| CVE-2021-33033      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-33033   |
| CVE-2021-3600       |  7.8 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3600    |
| CVE-2021-37576      |  7.8 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-37576   |
| CVE-2009-5155       |  7.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2009-5155    |
| CVE-2011-4116       |  7.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2011-4116    |
| CVE-2012-2663       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2012-2663    |
| CVE-2014-9900       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2014-9900    |
| CVE-2017-11164      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-11164   |
| CVE-2017-16932      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-16932   |
| CVE-2017-17740      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-17740   |
| CVE-2018-20796      |  7.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-20796   |
| CVE-2018-5709       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-5709    |
| CVE-2018-6829       |  7.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-6829    |
| CVE-2018-9234       |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-9234    |
| CVE-2019-12615      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12615   |
| CVE-2019-14855      |  7.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-14855   |
| CVE-2019-16229      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16229   |
| CVE-2019-16230      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16230   |
| CVE-2019-16231      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16231   |
| CVE-2019-16232      |  7.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16232   |
| CVE-2019-16233      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16233   |
| CVE-2019-16234      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-16234   |
| CVE-2019-18808      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-18808   |
| CVE-2019-19054      |  7.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19054   |
| CVE-2019-19060      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19060   |
| CVE-2019-19061      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19061   |
| CVE-2019-19064      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19064   |
| CVE-2019-19070      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19070   |
| CVE-2019-19075      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19075   |
| CVE-2019-20838      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-20838   |
| CVE-2019-9192       |  7.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9192    |
| CVE-2019-9674       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9674    |
| CVE-2019-9923       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9923    |
| CVE-2020-12062      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-12062   |
| CVE-2020-26556      |  7.5 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26556   |
| CVE-2020-26557      |  7.5 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26557   |
| CVE-2021-27218      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-27218   |
| CVE-2021-3326       |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3326    |
| CVE-2021-33560      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-33560   |
| CVE-2021-38207      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-38207   |
| CVE-2021-38371      |  7.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-38371   |
| CVE-2019-2213       |  7.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-2213    |
| CVE-2008-4609       |  7.1 |  AV:N  |     |      CERT | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2008-4609    |
| CVE-2017-11472      |  7.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-11472   |
| CVE-2021-29264      |  7.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-29264   |
| CVE-2005-2541       |  7.0 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2005-2541    |
| CVE-2020-0030       |  7.0 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-0030    |
| CVE-2020-1751       |  7.0 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-1751    |
| CVE-2020-1752       |  7.0 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-1752    |
| CVE-2021-41617      |  7.0 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-41617   |
| CVE-2013-0340       |  6.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2013-0340    |
| CVE-2019-6110       |  6.8 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-6110    |
| CVE-2019-20908      |  6.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-20908   |
| CVE-2020-13776      |  6.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-13776   |
| CVE-2020-15780      |  6.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-15780   |
| CVE-2020-27777      |  6.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-27777   |
| CVE-2021-28972      |  6.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28972   |
| CVE-2021-3640       |  6.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3640    |
| CVE-2021-43975      |  6.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-43975   |
| CVE-2008-3234       |  6.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2008-3234    |
| CVE-2018-5710       |  6.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-5710    |
| CVE-2019-17595      |  6.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-17595   |
| CVE-2019-19046      |  6.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19046   |
| CVE-2019-3874       |  6.5 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-3874    |
| CVE-2019-7148       |  6.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-7148    |
| CVE-2019-7149       |  6.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-7149    |
| CVE-2020-26141      |  6.5 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26141   |
| CVE-2020-26145      |  6.5 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26145   |
| CVE-2021-22922      |  6.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-22922   |
| CVE-2020-27835      |  6.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-27835   |
| CVE-2021-3752       |  6.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3752    |
| CVE-2019-12380      |  6.2 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12380   |
| CVE-2020-13529      |  6.1 |  AV:A  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-13529   |
| CVE-2015-8985       |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2015-8985    |
| CVE-2016-10228      |  5.9 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-10228   |
| CVE-2017-12132      |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-12132   |
| CVE-2018-1108       |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-1108    |
| CVE-2018-1121       |  5.9 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-1121    |
| CVE-2019-25013      |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-25013   |
| CVE-2020-14145      |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-14145   |
| CVE-2020-15802      |  5.9 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-15802   |
| CVE-2021-3772       |  5.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3772    |
| CVE-2007-6755       |  5.8 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2007-6755    |
| CVE-2018-16869      |  5.7 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-16869   |
| CVE-2019-12378      |  5.7 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12378   |
| CVE-2020-10029      |  5.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-10029   |
| CVE-2021-22923      |  5.7 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-22923   |
| CVE-2018-16868      |  5.6 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-16868   |
| CVE-2008-2544       |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2008-2544    |
| CVE-2011-4915       |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2011-4915    |
| CVE-2014-9892       |  5.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2014-9892    |
| CVE-2016-10723      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-10723   |
| CVE-2016-8660       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-8660    |
| CVE-2017-13685      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-13685   |
| CVE-2017-13693      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-13693   |
| CVE-2017-13694      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-13694   |
| CVE-2017-13695      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-13695   |
| CVE-2017-16231      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-16231   |
| CVE-2017-18232      |  5.5 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-18232   |
| CVE-2017-5969       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-5969    |
| CVE-2018-1000654    |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-1000654 |
| CVE-2018-10322      |  5.5 |  AV:P  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-10322   |
| CVE-2018-12928      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-12928   |
| CVE-2018-12929      |  5.5 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-12929   |
| CVE-2018-13095      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-13095   |
| CVE-2018-16403      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-16403   |
| CVE-2018-19211      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-19211   |
| CVE-2018-20449      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-20449   |
| CVE-2018-7273       |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-7273    |
| CVE-2018-7754       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-7754    |
| CVE-2018-8043       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-8043    |
| CVE-2019-0146       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-0146    |
| CVE-2019-0147       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-0147    |
| CVE-2019-0148       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-0148    |
| CVE-2019-0149       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-0149    |
| CVE-2019-11360      |  5.5 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-11360   |
| CVE-2019-12379      |  5.5 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12379   |
| CVE-2019-12381      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12381   |
| CVE-2019-12382      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12382   |
| CVE-2019-12455      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12455   |
| CVE-2019-12984      |  5.5 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-12984   |
| CVE-2019-19036      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19036   |
| CVE-2019-19039      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19039   |
| CVE-2019-20794      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-20794   |
| CVE-2019-7309       |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-7309    |
| CVE-2020-12363      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-12363   |
| CVE-2020-12364      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-12364   |
| CVE-2020-27618      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-27618   |
| CVE-2021-20193      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-20193   |
| CVE-2021-33098      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-33098   |
| CVE-2021-34556      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-34556   |
| CVE-2021-35477      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-35477   |
| CVE-2021-3669       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3669    |
| CVE-2021-3759       |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3759    |
| CVE-2021-37600      |  5.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-37600   |
| CVE-2021-45095      |  5.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-45095   |
| CVE-2020-26555      |  5.4 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-26555   |
| CVE-2016-10739      |  5.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-10739   |
| CVE-2016-20012      |  5.3 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2016-20012   |
| CVE-2018-15919      |  5.3 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-15919   |
| CVE-2018-7169       |  5.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-7169    |
| CVE-2019-1010024    |  5.3 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-1010024 |
| CVE-2019-1010025    |  5.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-1010025 |
| CVE-2019-1551       |  5.3 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-1551    |
| CVE-2020-14155      |  5.3 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-14155   |
| CVE-2021-28153      |  5.3 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28153   |
| CVE-2020-4788       |  5.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-4788    |
| CVE-2004-0230       |  5.0 |  AV:N  | POC |      CERT | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2004-0230    |
| CVE-2007-2243       |  5.0 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2007-2243    |
| CVE-2010-4563       |  5.0 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2010-4563    |
| CVE-2010-4756       |  5.0 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2010-4756    |
| CVE-2012-0039       |  5.0 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2012-0039    |
| CVE-2015-3276       |  5.0 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2015-3276    |
| CVE-2005-3660       |  4.9 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2005-3660    |
| CVE-2007-5686       |  4.9 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2007-5686    |
| CVE-2012-4542       |  4.9 |  AV:A  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2012-4542    |
| CVE-2018-17977      |  4.9 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-17977   |
| CVE-2013-4235       |  4.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2013-4235    |
| CVE-2017-0630       |  4.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-0630    |
| CVE-2017-14159      |  4.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-14159   |
| CVE-2017-18018      |  4.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2017-18018   |
| CVE-2018-16888      |  4.7 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2018-16888   |
| CVE-2020-27820      |  4.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-27820   |
| CVE-2021-33624      |  4.7 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-33624   |
| CVE-2021-43976      |  4.6 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-43976   |
| CVE-2019-19067      |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19067   |
| CVE-2019-9245       |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9245    |
| CVE-2019-9444       |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9444    |
| CVE-2019-9453       |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-9453    |
| CVE-2020-0067       |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-0067    |
| CVE-2020-14304      |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-14304   |
| CVE-2021-39636      |  4.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-39636   |
| CVE-2007-2768       |  4.3 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2007-2768    |
| CVE-2010-5321       |  4.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2010-5321    |
| CVE-2011-3389       |  4.3 |  AV:N  |     |      CERT | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2011-3389    |
| CVE-2020-15719      |  4.2 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-15719   |
| CVE-2010-0928       |  4.0 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2010-0928    |
| CVE-2011-3374       |  3.7 |  AV:N  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2011-3374    |
| CVE-2020-35501      |  3.4 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-35501   |
| CVE-2013-4392       |  3.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2013-4392    |
| CVE-2015-2877       |  3.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2015-2877    |
| CVE-2019-19126      |  3.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-19126   |
| CVE-2021-3601       |  3.3 |  AV:N  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3601    |
| CVE-2021-36084      |  3.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-36084   |
| CVE-2021-36085      |  3.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-36085   |
| CVE-2021-36086      |  3.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-36086   |
| CVE-2021-36087      |  3.3 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-36087   |
| CVE-2019-11191      |  2.5 |  AV:L  | POC |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-11191   |
| CVE-2021-27645      |  2.5 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-27645   |
| CVE-2019-20386      |  2.4 |  AV:P  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2019-20386   |
| CVE-2020-8991       |  2.3 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2020-8991    |
| CVE-2004-0971       |  2.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2004-0971    |
| CVE-2007-3719       |  2.1 |  AV:L  |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2007-3719    |
| CVE-2011-4917       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2011-4917    |
| CVE-2021-20320      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-20320   |
| CVE-2021-28711      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28711   |
| CVE-2021-28712      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28712   |
| CVE-2021-28713      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28713   |
| CVE-2021-28714      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28714   |
| CVE-2021-28715      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-28715   |
| CVE-2021-3847       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3847    |
| CVE-2021-3864       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-3864    |
| CVE-2021-39685      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-39685   |
| CVE-2021-4002       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4002    |
| CVE-2021-4037       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4037    |
| CVE-2021-4083       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4083    |
| CVE-2021-4095       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4095    |
| CVE-2021-4148       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4148    |
| CVE-2021-4149       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4149    |
| CVE-2021-4150       |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-4150    |
| CVE-2021-45469      |  0.0 |        |     |           | unfixed | https://nvd.nist.gov/vuln/detail/CVE-2021-45469   |
| TEMP-0000000-A4EF31 |  0.0 |        |     |           | unfixed |                                                   |
| TEMP-0000000-F7A20F |  0.0 |        |     |           | unfixed |                                                   |
| TEMP-0290435-0B57B5 |  0.0 |        |     |           | unfixed |                                                   |
| TEMP-0517018-A83CE6 |  0.0 |        |     |           | unfixed |                                                   |
| TEMP-0628843-DBAD28 |  0.0 |        |     |           | unfixed |                                                   |
| TEMP-0841856-B18BAF |  0.0 |        |     |           | unfixed |                                                   |
+---------------------+------+--------+-----+-----------+---------+---------------------------------------------------+

This issue was closed because it has been inactive.


add debian python-path.py

@rotu platforms need to be listed in alphabetical order

@ros/ros_team not sure how we should go from here.

This rule uses only pip versions of this package. Should we create a new key suffixed with -pip rather than adding new rules to this one?
This package is available upstream on most platforms.Ubuntu Debian, Fedora should we create a new key targeting this upstream version ?

It depends on if the Ubuntu package version is "new enough" for the ROS packages which currently depend on this key. If yes, I would say change the existing key (and only if there is a need for it also add a -pip entry). Even if no it should be considered to add the -pip entry and update existing ROS packages to use that one in order to update the non-pip entry to use the upstream packages.

@dirk-thomas Is there an automated way to find out which packages are using this key ? Given that it's pip I assume only non released packages use it but I don't know how to get a list of such packages

You could search through the repos registered with a source entry. But that doesn't cover any code not listed. So I would say no.

dev-python/path-py in gentoo (no pip)

@rotu This needs to be rebased to be mergable.

Closing due to no response.


Max stream number is limited incorrectly

4 stream types use one Stream ID space, so we cannot simply compare the number with a limit for max streams uni/bidi.

Fixed.


Infinite memory consumption, clickhouse

Environment

Python: 64 python 3.5.10
pyodbc: 4.0.30
OS: Ubuntu 20.04
DB: https://clickhouse.tech/docs/en/getting-started/playground/
driver: https://github.com/ClickHouse/clickhouse-odbc
unixODBC: 2.3.7

Issue
Hello, thx for great library! I think there's something wrong going on with memory reallocation in ReadVarColumn, consider test like this:
import pyodbc

def query(q):

    print("{} :".format(q))
    cursor = pyodbc.connect('DSN=ClickhouseTest').cursor().execute(q)

    for i, row in enumerate(cursor):
        print(i, row)

if __name__ == '__main__':
    query("SELECT repeat('a', 5000)")

where DSN looks like this
[ClickhouseTest]
Driver = ClickHouse ODBC Driver
Server = play-api.clickhouse.tech
Database = datasets
UID = playground
PWD = clickhouse
Port = 8443
Proto = https
Timeout=60
SSLMode = allow

In my system this script hangs out and eats all available memory.
And this is my trace, which also repeats infinitely
[ODBC][12501][1612779462.632364][SQLGetData.c][237]
		Entry:
			Statement = 0x5570d7dc4490
			Column Number = 1
			Target Type = -8 SQL_WCHAR
			Buffer Length = 4102
			Target Value = 0x7f257b78f4ec
			StrLen Or Ind = 0x7fff37fb3370
[ODBC][12501][1612779462.632408][SQLGetData.c][545]
		Exit:[SQL_SUCCESS_WITH_INFO]
			Buffer = [aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa](unicode)
			Strlen Or Ind = 0x7fff37fb3370 -> 8194

I wonder if this has to do with ClickHouse driver or server, as this doesn't happen when using Microsoft ODBC Driver 17 for SQL Server. The fact that SQLGetData with 'aaaaaa...' appears multiple times suggests that either the server keeps sending packets, or the driver fails to set completion status after giving the data causing it to be read again and again.

I don't know if it will help, when I change cbAllocated to bigger value, it works fine

Is it possible that the server or driver is resending the data we already read if the buffer wasn't large enough?

Absolutely yes, seems like bug I'd clickhouse driver


feat: update wallet-lib and dapi-client

Issue being fixed or feature implemented

Since we are using new error codes, we need to update wallet-lib and dapi-client
What was done?

Updated wallet-lib and dapi-client
How Has This Been Tested?

With tests
Breaking Changes

Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added or updated relevant unit/integration/functional/e2e tests
[x] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[x] I have assigned this pull request to a milestone

Duplicates #262


plugin: rate limit

implemented:
limit-req
limit-count
waiting todo:

[ ] limit-conn
[ ] limit-traffic

limit-conn: https://github.com/iresty/apisix/pull/75


WIP: Swift client

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 85.48%. Comparing base (8cf48b7) to head (219c3d9).
Report is 9 commits behind head on main.

Files with missing lines
Patch %
Lines

flipt-engine-ffi/src/lib.rs
0.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #472   +/-   ##
=======================================
  Coverage   85.48%   85.48%
=======================================
  Files           8        8
  Lines        3933     3933
=======================================
  Hits         3362     3362
  Misses        571      571

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Pixel History is not supported on OpenGL

Whenever i tried it, clicking on "History" or "Debug" in the Pixel Context pane always gave me an empty event list, even on pixels that clearly have been shaded.
I have a GTX 750 Ti, driver version 364.72, Windows 10, using OpenGL. i also tested it with another random OpenGL app (tesseract) i had on the machine.
separated from #293

I've noticed the same thing too. I was going to log an issue related to this.
AMD RX 470 Crimson ReLive Edition 17.2.1

Yeh as mentioned in #293, pixel history and shader debugging are only implemented on D3D11 currently. This issue is tracking for that feature being added.

Any plan to support this?

Any update on this?

Closed by #2865


Running rancher container on new host, unable to get into rancher.

Rancher Version:
Can't tell, since I can't bring rancher up, but this occurred with both rancher/server:latest and rancher/server:stable as of todays date.
Docker Version:
Docker version 1.11.2, build b9f10c9
OS and where are the hosts located? (cloud, bare metal, etc):
Ubuntu 14.04 on Azure
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Trying and initial setup of Rancher on a single node.
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
None yet.
Steps to Reproduce:
0. Provision new machine, install docker

sudo docker run -d --restart=always -p 8080:8080 rancher/server:stable
go to IPADDRESS:8080

Results:

brief flash of the animated rancher loading image
end up on blank screen with url: IPADDRESS:8080/env/1a5/waiting

Expected:
See rancher.

Is there anything in the rancher/server logs?
Currently, we technically only support Docker 1.10.3, but I don't believe that is the source of your issue.

Weird.  Deleted all the images and containers, then this morning re-ran step #1 and it worked.

Just in case:
In my case was that I pulled the latest version of rancher. I changed it for stable and everything when smoothly.


Adds babel

What?
Love you framework... a real lifesaver.
Since GoogleCloudFunctions run on node 6.14.0, and I had my Travis file set to that version, my tests were failing:

The reason being that async isn't available in 6.14.0

This PR adds a 6.14 save version of the code for NodeJS.
How?
Adds a compile script to package.json that runs the code through babel, that then, uses transform-async-to-generator plugins to convert async to generator*functions.
It also adds this step to the Webpack config so that the web-version is also able to run on browsers that don't support async.
It puts the code in the dist directory and changes the package.json to point to it in the main property.
It then bumps the version of the repo up to "version": "0.4.0"
The rest of the repo stays the same

hey @rmmmp that sounds ace...!
Just let me know if you need any help :)

Fixed in #18 which has been released as v0.4.0
I really appreciate your work here @fizk even though the PR didn't get merged.

@rmmmp no worries.. thanks for quick response :)


[Feature]: Integrated host/system metrics

Something to consider for an upcoming feature / roadmap:
Integrated metrics:

Host metrics
Rancher metrics

Right now I have a small cluster setup and the way I solve this today is with a "system service" configured like this in my user-data cloud-init config:
  services:
    node_exporter:
      image: prom/node-exporter
      command: '-collector.procfs=/host/proc -collector.sysfs=/host/sys -collector.filesystem.ignored-mount-points="^/(sys|proc|dev|host|etc)($|/)"'
      network_mode: host
      ports:
        - "9100:9100/tcp"
      volumes:
        - /proc:/host/proc:ro
        - /sys:/host/sys:ro
        - /:/rootfs:ro
      restart: unless-stopped

I then have Prometheus scrape data from all nodes in the cluster. One caveat to this is that the data you get back for the host (running Rancher OS)'s file system(s) is kind of messy and hard to deal with.

definitely. I too need to be able to gather metrics.


feature(plugin-seed): Add Replace "Your Plugin Name" to new plugin name

Replace "Your Plugin Name" to new plugin name in README, added some tests.
Removed some unused imports in e2e files.
Fix lint errors of missing and additional spaces.
Referenced issue #159

PR Checklist

[X] The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/CONTRIBUTING.md#commit-messages.
[X] There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
[X] All existing tests are passing
[X] Tests for the changes are included

What is the current behavior?
README file keep the same after the plugin postclone runs.
What is the new behavior?
Now when you build your new plugin README file will contain your plugin name.
Implements #159 .

run ci

test


Make LoadBalancer's round-robin parameter configurable

The parameter in the load-balancer that decides when to dispatch to the next invoker is hard-coded. We need to make the parameter configurable per environment by adding a property to WhiskConfig.
Property Name: loadbalancer_activation_count_before_next_invoker
Default Value: 10

Done by #1809.


Crash while pressing “submit” on a keyboard of a TextField

Issue:
I get a crash while pressing “submit” on keyboard of a TextField, that uses a published var from the viewModel.
“Thread 1: Simultaneous accesses to 0x600002e2b358, but modification requires exclusive access” on ObservableViewModel:25
Setup:
iOS viewModel is extending shared.ViewModel
on the viewModel side, the Published var used as input text binding for Textfield is defined like this:
@Published var username: String = "" {
        didSet {
            isUsernameValid = validateUsername(email: username)

            validatePasswordLogin()
        }
    }

ViewModel var inside the View is annotated with @StateViewModel
struct LoginView: View {
    @StateViewModel var viewModel: LoginViewModel

    var body: some View {
        TextField(text: $viewModel.username, label: {
            Text("test")
        })
    }
}

Proposed fix:
Since simultaneous access could be avoided by doing the writing async, i tried the following and it fixed the crash - no idea if its a worthy solution here.
ObservableViewModel:35 - the function that does the setting of keypath, i wrapped that line inside a DispatchQueue.main.async
     public func set<T>(_ keyPath: WritableKeyPath<ViewModel, T>, to newValue: T) {
        DispatchQueue.main.async {
            self._viewModel[keyPath: keyPath] = newValue
        }
     }

Versions on the iOS side:
pod 'KMMViewModelCore', :git => 'https://github.com/rickclephas/KMM-ViewModel.git', :commit => '047d8c597715d57be2951d121f686c2886e5a39f'
pod 'KMMViewModelCoreObjC', :git => 'https://github.com/rickclephas/KMM-ViewModel.git', :commit => '047d8c597715d57be2951d121f686c2886e5a39f'
pod 'KMMViewModelSwiftUI', :git => 'https://github.com/rickclephas/KMM-ViewModel.git', :commit => '047d8c597715d57be2951d121f686c2886e5a39f'

Hi, sorry for the delay!
Was able to reproduce this and it was indeed caused by _viewModel[keyPath: keyPath] = newValue.
However since the viewmodels are all classes we don't actual need a mutable variable for the keyPath.
Fix has been released in v1.0.0-ALPHA-6!


[BUG] When using same single tooltip on page but changing delayShow, tooltip shows after mouseleave

Bug description
If you are using one tooltip component and then different elements change the delayShow prop, it will show the next tooltip after mouseleave.
Version of Package
v5.26.4
To Reproduce
Use one component <ReactTooltip  id="test"/>
Then use data-tooltip-id="test" on multiple elements. Give elements different values for attribute data-tooltip-delay-show
Then hover on the first element using that tooltip, and mouseleave the element and see tooltip delay show
Expected behavior
I would expect the tooltip to delay show, then hide, and remain hidden until I hovered on another element
Screenshots

Desktop (please complete the following information if possible or delete this section):

OS: Sonoma  14.5
Browser Chrome
Version 126.0.6478.127
Frameworks React 18

Additional context
Add any other context about the problem here.

This does not seem like an issue with just the data-tooltip-delay-show attribute.
It mainly relates to the tooltip anchor being unmounted after triggering the tooltip with the delay. I've managed to create a simple example reproducing the issue.
https://stackblitz.com/edit/vitejs-vite-bbqqcx?file=src%2FApp.tsx
https://github.com/ReactTooltip/react-tooltip/assets/21102974/7514b07c-5e22-4880-9cd3-de0d01e9f483
I might be able to get to this this week, so we'll let you know when we have a fix for it.

This beta release should fix it<EMAIL_ADDRESS>Please let us know if it works for your project, and check PR #1205 for more info if you're interested.
Assuming it is fixed for you, we will close this as soon as we release an official version with the fix.

Yes, this code fixes the issue in my project. Thank you!

Official release with the fix<EMAIL_ADDRESS>


[BUG] async client with basic http_auth results throw an error (TypeError) #283

What is the bug?
May be it is similar to https://github.com/opensearch-project/opensearch-py/issues/283
When testing async client with basic auth (login and password auth):
client = AsyncOpenSearch(
  hosts=[{
    'host': OS_HOST,
    'port': OS_PORT
  }],
  http_auth=(OS_USER, OS_PASSWORD),
  use_ssl=True,
  verify_certs=True,
  connection_class=AsyncHttpConnection,
  timeout=30
)

I have catch an error:
  File ".../opensearch_async.py", line 125, in wait_for_start
    response = await self.cluster.health(wait_for_status=status)
  File ".../venv/lib/python3.10/site-packages/opensearchpy/_async/client/cluster.py", line 78, in health
    return await self.transport.perform_request(
  File "../venv/lib/python3.10/site-packages/opensearchpy/_async/transport.py", line 374, in perform_request
    status, headers_response, data = await connection.perform_request(
  File "../venv/lib/python3.10/site-packages/opensearchpy/connection/http_async.py", line 196, in perform_request
    **self._http_auth(method, url, query_string, body),
TypeError: 'str' object is not callable

How can one reproduce the bug?
Initialize and use AsyncOpenSearch client with basic http_auth (i.e with use OS on docker for example) and make a call to info()
What is the expected behavior?
Successful response the information from OS.
What is your host/environment?
OS: 12.6.5
Python: 3.10.11
opensearch-py: 2.2.0
Do you have any additional context?
I think there is a simple mistake in code. Was forgotten http_auth argument in init block:

https://github.com/opensearch-project/opensearch-py/blob/05326ba5474c1a1f5c1975760a4e37037f967dda/opensearchpy/connection/http_async.py#L56-L65
And this should be removed:
https://github.com/opensearch-project/opensearch-py/blob/05326ba5474c1a1f5c1975760a4e37037f967dda/opensearchpy/connection/http_async.py#L193-L196

I've create a PR

Hello @GRomR1, I attempted to reproduce this issue but couldn't observe any problems. Please refer to the guide for assistance. If you encounter any further issues, please don't hesitate to reopen this matter. Thank you!


mbed-os-example-uvisor doesn't work on EFM32GG_STK3700

It should work. Make it work please.

ARM Internal Ref: IOTSEC-287


Configuring Github App for Organization

Your Question
I followed https://github.com/shapehq/tartelet/wiki/Configuring-Tartelet to create and configure the Github App for my organization. I was having trouble getting the runner to run locally, and in the midst of fuddling around trying to fix it, I came stumbled upon this Install App menu option on https://github.com/organizations/{YOUR_ORGANIZATION_NAME}/settings/apps:

It seemed necessary, so I did it for my org.
Was this a required step? I don't see it mentioned in the guide to configuring the github App for an organization.
Any additional context?
No response

I have just been through the same journey again, although this time we refactored our github apps a bit to create a specific one just for the runners registered using tartelet.
I can confirm that I also had to "install" the app into the org after creating the app, you did the correct thing ✅
(Don't remember if it was like that last time I set it up as that was a couple of years ago now.)

It is indeed necessary to install the GitHub app on the organization. I've updated the guide to reflect this requirement. Thanks for pointing out the missing step.


Error when creating an invoice

Bug report
Exception when creating an invoice
Method: store/invoiceController.
Description
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (flaya_import.bagistoinvoices, CONSTRAINT invoices_order_address_id_foreign FOREIGN KEY (order_address_id) REFERENCES bagistoorder_address (id) ON DELETE SET NULL) (SQL: insert into bagistoinvoices (order_id, total_qty, state, base_currency_code, channel_currency_code, order_currency_code, order_address_id, updated_at, created_at) values (3, 1, paid, USD, USD, USD, 13, 2020-07-19 00:28:12, 2020-07-19 00:28:12))
1. Bagisto V1.1.2
2. PHP V7.3,18
3, Composer V1.10.9

Steps to reproduce
It is important to provide a set of clear steps to reproduce this bug.If relevant please include code samples.
1. Go to orders details
2. Invoice
3. Save Invoice

Expected result
The invoice cannot be saved because of  exception.

Feel free to reopen in case of any doubt.


Outdated Lib.Harmony version on NuGet

The Issue
There is a problem with the lowest version for Lib.Harmony which the OWML NuGet requires. As its dependencies, it requires  Json.Net.Unity3D (>= 9.0.1) and  Lib.Harmony (>= <IP_ADDRESS>). The Harmony library has two different namespaces depending on the version that you are using, Harmony for versions <= 2.0 and HarmonyLib for versions >= 2.0, which indicates that neither are compatible, and this is where the problem lies.
For some reason the NuGet, instead of getting the latest Harmony version, uses the lowest one allowed (<IP_ADDRESS>):

And, OWML uses the <IP_ADDRESS> version:

This means that when you use the NuGet you can't use Harmony as normal in a mod, because not only you are using an incompatible version but the namespaces are different.
Some points to note
As you might notice, while Harmony doesn't work, the ModHelpers for it do. I theorize that, because you are not interacting with the 0Harmony.dll namespace, you don't get this incompatibility issue.
A possible fix
Maybe by updating the OWML NuGet to require a version that is >= 2.0 this issue will be fixed.

Hi, try using HarmonyX in your mod:
<PackageReference Include="HarmonyX" Version="2.5.5" />
It's a different package, a port of Harmony.
OWML referencing an old version of Harmony seems to be a bug, but shouldn't be an issue if you use HarmonyX instead of Harmony. Let me know how that works out.

It indeed worked out, many thanks. I think the ModTemplate should tell about referencing it or it should have it already referenced in the .csproject.

I think this has been fixed. Closing the issue, let me know if it's still an issue.


Add known issue for a[download] in Chrome 65+

Chrome no longer supports cross-origin download links.

Thanks!


Logger Logs application/json as Hex

Despite being text, is considered a binary format. So is logging as HEX, this should instead log as text

FYI here's where application/json is marked as binary.
The comment there (and on application/hal+json and application/problem+json is:

we treat JSON as binary, since it's encoding is not variable but defined by RFC4627

Fixed by #1362 on release-0.17.x and will be fixed in master on roll-forward.


Polyglot project design.

Makes this a polyglot project, which has its trade-offs, but I'd sure be happy.
Out of curiosity, what does this mean, if anything, for the prospects of a full Kotlin rewrite? I know some of the llamas crowd has strong negative opinions about Java, and Kotlin might possibly be more attractive to some of them.

If someone is willing to do the work, sure. Or if we want to just compile incrementally side by side with Java and Kotlin.
My suggestion would be then to separate the Java and Kotlin into separate subprojects, so that we can have full polyglot cross-compilation, and so that each subproject is aware of the others, regardless of their language.
In this scenario, we could have subprojects for each language we can support: Scala, Groovy, Kotlin, Java, Clojure, etc.
I think it makes the most sense to keep the interfaces in Java, in their own subproject, and if we were to rewrite, or if we just want to expand with new logic in other languages, a contributor can implement the interfaces in whatever language they desire.
Thoughts?
Originally posted by @wodencafe in https://github.com/IRC-Llamas/cardlogic/issues/6#issuecomment-1179583214

I actually am against supporting more than 2 languages without a very specific reason to do so. Otherwise, I'd have pushed for Scala 3 before Kotlin.
By adding multiple languages, you make it that much harder for one person to be able to work on any part of the codebase. This is especially the case with rarer languages like Scala, Clojure, Groovy (yes, Gradle build scripts use Groovy by default, but how many people are actually skilled with Groovy?). For a project that's supposed to be easy to get into for randoms in an IRC community, that's a problem.
However, I'm okay with Kotlin being a part of the project. It's probably the easiest-to-learn (for Java devs) major JVM-targeting language, and it provides quite a few benefits over vanilla Java.

@TheDaemoness
Fair enough. Perhaps this should focus on how best to implement Kotlin as a development alternative to standard Java.
We can revisit the idea of further polyglot exploration (other languages) when we can identify a compelling use case.

Update: #36 exists following some talk on IRC about adding Groovy.
Teasing aside, I think it could be alright for writing tests. We're not strict about TDD, so it's not critical that tests and code be able to be written by the same people. There are undeniable benefits, but it's not like we can't write the tests in a separate pass.
There's also been a soft agreement to start porting the domain classes to Kotlin. I'll be doing that over the next few days.
I think this is the limit of what's reasonable for polyglot in this project.


Can build.sh please not randomly bind interfaces even if the build failed

make: *** [all] Error 2
Trying to bind interfaces, this will fail if you are not root
Try sudo ./bind-interfaces.sh if this step fails
Binding interface 0000:07:00.0 to DPDK
Binding interface 0000:0a:00.0 to DPDK

don't run it as root


Bugtool: Fix header size on Tarball files

Currently in the bugtool the tar file is not created because the size for
elf objects [1] are not correct in the fileInfo so the bugtool fails and
no data can be retrieved.
With this change we make sure that we send the correct size in the file.
Error:
vagrant@k8s1:~$ kubectl -n kube-system  exec -ti cilium-mvzwp -- bash
root@k8s1:~# cilium-bugtool
Deleted empty directory /tmp/cilium-bugtool-20190320-150406.345+0000-UTC-372992147/cmd
Deleted empty directory /tmp/cilium-bugtool-20190320-150406.345+0000-UTC-372992147/conf
Failed to create archive archive/tar: write too long
root@k8s1:~#

[1] File that fails: /var/run/cilium/state/templates/93e0f422d723d70b202357a3c412f26374f8e233/bpf_lxc.o
Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This change is

test-me-please

Coverage decreased (-0.006%) to 42.322% when pulling 20021f2bab023f24faf1128577ffe85bf9823ce3 on eloycoto:FileTooLong into 80912fc6cb2b2dd6ef92cec3080c66d33d36a925 on cilium:master.


Unable to run Sudomy in Docker

I'm getting this error when trying to pull from Docker Hub
⋊> ~ docker pull screetsec/sudomy:v1.1.6-dev
Error response from daemon: manifest for screetsec/sudomy:v1.1.6-dev not found: manifest unknown: manifest unknown

Anyone has figure out how to solve?

You can see available tags in here https://hub.docker.com/r/screetsec/sudomy/tags, I think the README.md have wrong tags about docker tags.
Thankyou

It’s true. I will open a PR for that.


Fixed the clang #if

Coverage remained the same at 99.833% when pulling ba0e726623b3639beffa8e2c691787719db32acb on basvodde:master into 4ce07ab57bb19c56518af7e2fdc29416067a687b on cpputest:master.


Mattermost redux rethreading

Summary
Adds a new feature: rethreading. Posts not included in threads can be moved to existing threads, or a new thread can be created with another post not in threads. Rethreading can be done by the posts creator (and any system admin or team admin if he/she has permissions to edit the post).
Ticket Link
None.
There is the Mattermost forum post:
https://mattermost.uservoice.com/forums/306457-general/suggestions/34136164-add-ability-to-move-mistaken-thread-replies-in-a-c
and mattermost feature channel
https://pre-release.mattermost.com/core/pl/13zruhcrfidtxqi9s6m8tu54fe
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Ran make check-style to check for style errors (required for all pull requests)
[ ] Ran make test to ensure unit tests passed
[x] Ran make flow to ensure type checking passed
[ ] Added or updated unit tests (required for all new features)
[ ] All new/modified APIs include changes to the drivers

Test Information
This PR was tested on: [Device name(s), OS version(s)]

Thanks @kkekkonen for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

new changes: added stuff to reducer to trigger post-rethread replycount changes for users after rethread is complete

Moving this and the server PR to dev review so that the PM/designers can test the web app PR

@hmhealey @lieut-data looks like there have been updates since last review, have your comments been addressed here?

Unit tests still need to be added, and there's also been a bad merge that needs to be resolved since there's a bunch of unrelated commits from master included in here as well

cc// @kkekkonen on the above when you have a chance ^

After discussing with @kkekkonen, I will close this and the related pull requests, but keep the branches open so work can be easily continued later on.
The work halted here as a result of our process failures. In particular,

there was no owner for these PRs, leading to slow response times from the Mattermost team
there was no ticket, nor no design, prior to submitting the PRs, leading to

Mattermost team giving confusing feedback (too high-level)
uncertainty and inconsistency about the direction of the feature
conflicting reviewer feedback, in some cases leading to contributor reverting his changes back

We've taken notes and started discussions on how to address the above - we'll start by having a JIRA ticket for every contributor pull request that details the expected behaviour and design, and have an owner for each.


Milestone 2 code feedback

R Repo looks good. Like I had spoken to this group in the lab, please delete the branches for the Python Repo
Python Coding:
Unused variable:
Undefined variable ‘alt’
Or Unused variable like ‘sourceFont’ ‘axisColor and ‘gridColor’
I think this is because of discrepancies, and tests ran fine even when there were these errors. Mostly occurring in mcgill and Toronto. Should be fixed with the dependencies fixed with continuous integration with poetry.
Python Tests:
All of the python tests worked Great job.
R coding:
Rcoding looks fine
R tests:
I think again there is some sort of discrepancies in terms of test for R. No marks will be deducted.

@andytai7 Could clarify what you mean by discrepances with respect to the R test functions?


OpenIdConnect flow does not set the SignInAsAuthenticationType cookie

Checkin : https://github.com/aspnet/Security/commit/3483842ab76d4198fc230c7a1905b0ada9b4bf89#commitcomment-9535319 seems to break openIdconnect flow as it does not set the external cookie.
Test failure here : https://github.com/aspnet/MusicStore/commit/7783c368569fbaf267121eff8eedefbd05cb974d is due to this.

On a side note, OpenIdConnectAuthenticationMiddleware doesn't use a correct value for TokenValidationParameters.AuthenticationType: it should use Options.AuthenticationType instead of externalOptions.Options.SignInAsAuthenticationType to make sure that the ClaimsIdentity returned by AuthenticateCoreAsync has the same AuthenticationType as the middleware itself.
https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNet.Security.OpenIdConnect/OpenIdConnectAuthenticationMiddleware.cs#L51

@brentschmaltz


"unknown" XFF address

See https://accounts.wmflabs.org/acc.php?action=zoom&id=141848, which has an "unknown" address in the XFF header.
Not exactly sure how we should handle these at the moment (maybe just remove the links as if it were a trusted address?), but there is no real point in showing users links to information related to User:Unknown here.

Actual XFF header contains unknown, <IP_ADDRESS>, <IP_ADDRESS> (data sanitised for privacy), with IP <IP_ADDRESS> (internal proxy). We should actually parse the IPs individually, and sanity check that each is an IP address, remembering to check IPv4 and v6 addresses.
It's my preference to add a new option to the proxy array, which marks it as an errored IP, and pass in the error reason. This is the template.
{if $proxy.error} Trust label should probably be "failed" (red), then the rest of the rows should be colspan'd together with {$proxy.errormessage}.
In the code behind, we should attempt a parse of the IP, and set those two array keys as appropriate, as well as revoking trust for the rest of the chain?
Does this sound like a reasonable fix?
Also, while someone's there, can the whitespace be fixed? Right now, GitHub is interpreting the mismatch of tabs/spaces and messing it all up. :cry: We probably ought to agree on a standard anyway.

I just dealt with the whitespace using Scrutinizer (from my fork, since I don't have access to apply its patches directly to here). At least for now, everything in zoompage.php is tab indented.

Fixed (discarded) by @FastLizard4 in #465

@stwalkerster Do we actually want to close this?  IIRC, you wanted to come up with a better way of handling this in newinternal


Add metrics to benchmarks

Auto-generates line of code counts and docker image size
Formats as HTML to facilitate loading into website

We could improve this a touch with template files but no reason to keep this from getting merged right now.


Do not autofill post complete tags

When you type "water" tag it gets auto filled with "waterway". So you have to delete -"way" manually.
It would be better not to make any autotype suggestions for complete tags.

Can you show me a screenshot of which field is doing this?
If it's the raw tag editor, what did you enter for the key ?

If it's this - I don't know if we can change it.  The results are ordered by popularity.
Honestly, just deleting the "way" or using the downarrow to pick the one you want should be no big deal.

Yes, it is about this one.

Here is the full case which actually moved me to submit this ticket.

I type in "water"
Pressed Tab key
Started typing "la.." and was expecting to get "lake" in the dropdown but it did not come up
So I went back to the key field and was surprised to find out that there was "waterway" instead of "water" in there.

From then on when I type "water" I know that I have to wait for a second for the autofil to appear, delete it and only then press Tab key.

Ever happen when you type Water, goes straight to Waterway


Refactor upgrade tests preparation to simplify code

Type of change

Refactoring

Description
This PR moves the preparation for UpgradeTest from the afterAll callback to the beforeAll callback, this is being done to get rid of the method isNextTestUpgrade in TestInfo class. IMO we should avoid the kind of logic that were in methods like isNextTestUpgrade

Checklist

[ ] Update/write design documentation in ./documentation/design
[ ] Write tests and make sure they pass
[ ] Update documentation
[ ] Check RBAC rights for Kubernetes / OpenShift roles
[x] Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
[ ] Reference relevant issue(s) and close them after merging
[ ] Update CHANGELOG.md

@enmasse-ci run tests profile=upgrade test_only upgrade_from=0.30.2

:heavy_check_mark: Test Summary :heavy_check_mark:
TEST_PROFILE: upgrade
TEST_CASE:
TOTAL: 2
PASS: 2
FAIL: 0
SKIP: 0

@enmasse-ci run tests profile=upgrade test_only upgrade_from=0.28.4,0.29.2,0.30.1

:heavy_exclamation_mark: Build Failed :heavy_exclamation_mark:

@enmasse-ci run tests profile=upgrade test_only upgrade_from=0.28.4,0.29.2,0.30.1

:heavy_exclamation_mark: Build Failed :heavy_exclamation_mark:


Scroll first error into view after ajax validation

Current behavior
On form submit, in case of validation error problematic fields are highlighted
Suggested behavior
Current behavior + scroll first error into view (if any)

Nice idea, i didnt think about add it, thanks for this, i hope @marktopper add it, this is good improvement.


Add Support for Heltec BMS (= YYBMS YanYang)

Is your feature request related to a problem? Please describe.
I read on https://github.com/Louisvdw/dbus-serialbattery/wiki/BMS-types-supported that "JKBMS / Heltec BMS" are supported, so I tried to connect my Heltec Smart BMS 9-25S 100A RS485 but it is not detected by the dbus-serialbattery driver.
Describe the solution you'd like
According the docs I have (and what I spied on the RS485 with the scope) the BMS seems to talk Modbus RTU and is different from the JKBMS. So I propose to add support for this Heltec device. I don't know about other Heltec BMSs and if there is a variant that is compatible to JKBMS, but we might also want to update the docs accordingly.

I am working on this. @Louisvdw  @mr-manuel should I base that work directly on the JKBMS-BLE branch?

If you are not adding a BLE driver than you can merge with the master branch. The only thing is that there are a lot of changes outstanding, see https://github.com/Louisvdw/dbus-serialbattery/pull/468.
If you are adding only a new python file and the corresponding additions to include the file it should not be hard to merge.

OK thanks. The config.ini seems to be a very interesting change there... maybe the timeline to merge that into master us the main question right now

Unfortunately @Louisvdw has not much time right now, but he will do so after 2nd May. If you want to keep it simple merge with the jkbms_ble branch, than I can review your PR and merge it directly.


Parsing fails with bytes32 and address

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (3cdee82 2024-02-15T00:16:41.175930486Z)
What command(s) is the bug in?
forge test
Operating System
Linux
Describe the bug
Parsing a json file as the following struct fails unexpectedly with Reason: EvmError: Revert:
struct S {
        bytes32 id;
        address addr;
    }

Parsing is done on example.json:
{ "id" : "0x1111111111111111111111111111111111111111111111111111111111111111", "addr": "0x0000000000000000000000000000000000000000"}

using the following snippet:
        string memory projectRoot = vm.projectRoot();
        string memory path = string.concat(projectRoot, "/example.json");
        string memory json = vm.readFile(path);

        abi.decode(json.parseRaw(""), (S));

For convenience, this is reproduced here. Notice that if you switch the order of the fields in the struct, then it goes through.

can take this one, using serde_json::Map (which is backed by a BTreeMap) here https://github.com/foundry-rs/foundry/blob/master/crates/cheatcodes/src/json.rs#L371 should solve it

can take this one, using serde_json::Map (which is backed by a BTreeMap) here https://github.com/foundry-rs/foundry/blob/master/crates/cheatcodes/src/json.rs#L371 should solve it

hm, actually this will probably break backward compatibility so don't think it's a good idea


When does generic resolution happen?

[Enter feedback here]
Dear reader,
On stack overflow I see a lot of questions about using generics in combination with method overloading, Like this one:
https://stackoverflow.com/questions/3678703/generic-overload-resolution/3678758#3678758
In my understanding generics can not be used for method overloading, because method resolution happens at the initial compile time to IL (generating an assembly). And generics resolution happens once during JIT (generating machine code). But I am not completely sure if this is true.
Could you maybe explain in this article when generics resolution happens, so this might also be more clear for other people on stackoverflow?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a00cbfda-8501-d26a-9293-56a2e0d131ad
Version Independent ID: 2f4c4f67-5c8f-5aa8-0db5-9c300486cada
Content: Generic classes and methods
Content Source: docs/csharp/fundamentals/types/generics.md
Product: dotnet-csharp
Technology: csharp-fundamentals
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

I'm putting this in our backlog. We can do better here.  Adding a couple initial comments in case a community member wants to submit a PR:

Generics do participate in overload resolution. Paraphrasing the spec, there are two important rules:
A non-generic method where all parameters are an exact match is preferred over a non-generic method.
type parameters are replaced by the type of the argument, which makes a generic method a better match than a non-generic method requiring an implicit conversion (other than an identity conversion).
I think your comment on the JIT is misleading. I think what you're saying is that the JIT generates the machine code for closed generics, which is true for type arguments that are value types.


fix open by default app and expose default app

needs: https://github.com/cs3org/cs3apis/pull/157
needed because of https://github.com/owncloud/web/pull/5970#issuecomment-958745928
After this PR the /app/list endpoint will provide a default app (if configured):
    {
      "mime_type": "application/vnd.oasis.opendocument.text",
      "ext": "odt",
      "app_providers": [
        {
          "name": "Collabora",
          "icon": "https://www.collaboraoffice.com/wp-content/uploads/2019/01/CP-icon.png"
        }
      ],
      "name": "OpenDocument",
      "description": "OpenDocument text document",
      "allow_creation": true,
      "default_application": "Collabora"
    }

@glpatcern I updated the CS3apis, can we get this in?

(did not merge yet because I'm not code owner - will check with @ishank011 also to update the CODEOWNERS rules for those subtrees)


Support for partial response

Is your feature request related to a problem? Please describe.
Currently it is not possible to have partial responses by using this graphql client as described in here

https://spec.graphql.org/October2021/#sec-Errors.Field-errors
https://spec.graphql.org/October2021/#sec-Errors.Error-result-format

Describe the solution you'd like
We are using this graph client for a big project and need to be able to receive 200 OK responses when graphql field errors occur.
This is also described in the graphql spec and therefor should be a feasible feature addition to this client.
So the most easy thing is to have an additional option/parameter to specify how the client should handle responses with errors.
Therefore we added 	allowPartialResponse?: boolean to the FetchOptions, because we think it allows to implement this feature in the most minimal invasive and backwards compatible way.
See #95 for all the implementation details.
This means the response would look like this:
HTTP 200 OK
{
  "errors": [
    {
      "message": "Name for character with ID 1002 could not be fetched.",
      "locations": [{ "line": 6, "column": 7 }],
      "path": ["hero", "heroFriends", 1, "name"]
    }
  ],
  "data": {
    "hero": {
      "name": "R2-D2",
      "heroFriends": [
        {
          "id": "1000",
          "name": "Luke Skywalker"
        },
        {
          "id": "1002",
          "name": null
        },
        {
          "id": "1003",
          "name": "Leia Organa"
        }
      ]
    }
  }
}

Describe alternatives you've considered
The feature could be implemented in the following ways, as we thought of it:

Introduce additional "request" methods e.g. "requestPartial<>"
Add another "options" parameter to the request methods
Add another option to the client settings (similar to what the apollo client has implemented https://www.apollographql.com/docs/react/data/error-handling#graphql-error-policies)
Check if there are field errors + valid data (if deterministicly possible) and always return a partial response -> this would be a breaking change

Additional Context
My team and me considered the following options on how to deal with the problem

Change to a different graphql client which fulfills all of our requirements (bigger change we want to prevent currently)
Fork this client and add the code to our repo (if it can be avoided we would prefer to just continue using the client as package)
Implement the feature our self and make an MR

So we hope we can get this PR accepted, instead of having to go for one of the other options.

Hi! Thanks for such a detailed description, it was really helpful.
I'm preparing a solution where I would always return a partial data from a requestSafe method. It would return like this
Promise<
    | { ok: true; data: TData; response: TRequestResult }
    | {
        ok: false
        data?: DeepNullable<TData>
        error: GraphQLRequestError<TRequestResult> | Error
      }
>

And GraphQLRequestError would have all the fieldErrors as a field
export class GraphQLRequestError {
    fieldErrors?: GraphQLFieldError[]
    // ...
}

So it would not require setting a new option.

Have you considered using GraphQL union types for expected errors (like validation errors) instead of throwing an error on server? The server could return something like
type ValidationError {
  code: String!
  message: String!
}

union Result = MyModel | ValidationError

type Mutation {
  foo: Result!
}

Thanks for responding so quickly!
Im glad you found the description helpful :)
Would be quite similar to the solution from the MR, except the new option, so the nullable "data?" property should work for us 👍
I guess it would still return HTTP 200 ok in that case or are you planning on sending a different HTTP Statuscode?
What im unsure about is this:
export class GraphQLRequestError {
    fieldErrors?: GraphQLFieldError[]
    // ...
}

Since the property name "fieldErrors" would also be serialized in the response, it would kinda break with the GraphQL spec i had linked or maybe did i understand something wrong here?

Our backend is .NET and we are using the Hotchocolate GraphQL package (https://chillicream.com/docs/hotchocolate/v12).
Mutations are not the main reason for why we need this.
Rather we have some nested object trees and ACLs (like ABAC) for some properties/objects.
So if the current user is not authorised to access those sub data, then the resolver throws an field exception for that currently.
We dont just want to return null because then we dont easily know if there is no data or if the user can't access it.
Hope this makes our usecase more clear.

Should work for us, thanks for the quick implementation! :+1:
Sry about the GraphQLRequestError confusion, i mixed up the client and server side there but everything is clear now.

Solved in https://github.com/lynxtaa/awesome-graphql-client/releases/tag/v2.1.0


Added protected ctor to AuthenticationSchemeProvider

Closes https://github.com/aspnet/Home/issues/2827
This will let me derive from AuthenticationSchemeProvider, pass in StringComparer.OrdinalIgnoreCase instead of the default StringComparer.Ordinal, and swap the implementation in the container.
It does not affect registration in any way (SchemeMap in AuthenticationOptions is still case-sensitive), but it will let me do scheme lookups without having to worry about the correct casing. I.e. github and GitHub will both return the correct scheme.
Personally, I'd prefer to take it one step further by adding a SchemeNameComparer option to AuthenticationOptions (as shown in this branch). That would allow me to skip the custom class altogether and just set the property on the options object.
What do you think? Too crazy? 😄
// @HaoK @davidfowl @Eilon @Tratcher

Thanks @khellang

Thank you! ❤


issue-20 Get libmysqlclient separately

Pull request questions
Which issue does this address
ISSUE-20
Why was change needed
The container was root and mutable.  Also ODBC support needed to be removed.
What does change improve
Although still a root container, it can be run as non-root.

#20


feat: Adding scroll to top button

Description
Adding scroll to top button
Screenshots
No response
Ready to Work?

[ ] I want to work on this issue

I would like to make this issue

@IvySaskia assigned to you

Hi @oyepriyansh i want to contribute to this task, please assign to me


Design system information architecture

Create an information architecture infrastructure that contains the following:

A homepage to serve as a storefront for the Design System
Principles for each discipline
Style guides
Components
A standard component template

cc @wrendo

The site architecture in Adam's latest figma is looking great, ok to close this ticket now @wrendo?

Looks good! will close.


Address alignment in go

So I am using AVX instructions (basically using MultiplyAndAdd.cpp). I modified the code of .cpp a bit, and following is the new and the old (unmodified code) snippet of  MultiplyAndAdd.s files:
New:
    vmovaps ymm0, YMMWORD PTR [rdi]
    vmovaps ymm1, YMMWORD PTR [rdx]
    vfmadd132ps     ymm0, ymm1, YMMWORD PTR [rsi]
    vmovups YMMWORD PTR [rcx], ymm0
    vzeroupper
    ret

Old:
push	rbp
mov	rbp, rsp
vmovups	ymm0, ymmword ptr [rdi]
vmovups	ymm1, ymmword ptr [rsi]
vfmadd213ps	ymm1, ymm0, ymmword ptr [rdx]
vmovups	ymmword ptr [rcx], ymm1
pop	rbp
vzeroupper
ret

As you can see, old code is using "vmovups", which allows unaligned address, but new code is using "vmovaps", which requires aligned address (256 bits aligned as this is AVX). Go seems to only allow upto 128bit alignment, when using complex128, so we can never be guaranteed of 256 bits alignment. I am assuming "vmovups" will be slower than "vmovaps".
So, the questions is, is there a way to get 256 bit alignment in go?
Also, there seems to be an issue. When I am using c2goasm/test/cpp/assembler.sh, the .s file that I get is not compatible with c2goasm. The reason is that the assembler is c++ assembler so it mangles the function name, so c2goasm is not able to find the corresponding function declaration in .go file. So I have to use extern "C" {} in .cpp file to ensure the function names are not mangled.
So another question is, are the .s files (in c2goasm/test/cpp/ folder) hand crafted and not created using assembler?

Unfortunately explicit alignment is a bit of a problem in Golang. One possible way (but ugly solution) is to allocate more memory and "round up" the pointer to the next multiple of the address alignment that you want.
What C++ compiler are you using? We have been running it under OSX:
$ c++ -v
Apple LLVM version 9.0.0 (clang-900.0.37)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


Don't updateUrl on isOnLoadCall

Closes https://github.com/huggingface/moon-landing/issues/4542

CI is failing on unrelated issue to this PR


Canonical URL for "latest" page wrong?

https://pub.dartlang.org/documentation/angular/latest/
Has a canonical URL of https://pub.dartlang.org/documentation/angular/4.0.0+2//index.html
1 - Extra slash is sad
2 - Doesn't feel like it aligns w/ discussion here https://github.com/dart-lang/pub-dartlang-dart/issues/1017#issuecomment-378746468
We want the canonical URL to be stable – https://pub.dartlang.org/documentation/angular/latest/ – so search engines aren't constantly linking to different pages as the content updates

cc @isoos


storage: cas: avoid memory additional allocation on GetBatch()

Problem
Now, in current architecture
A clear and concise description of what the problem is.

Problem (hot):
Problem (warm):

Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

@host6


[WIP] Selective language support

This PR introduces support for selectively loading language files. Right now all language files are always loaded. With this PR, the developer can decide which language files to require. During test instruction compilation, the language used can be chosen. This allows us to scale this project to large numbers of languages, without bloating data downloaded in browsers for all users.
The module API as well as internal APIs have breaking changes, since we had to change several function signatures.
TODOs

[x] Integrate PR within Mapbox (to see what breaks)
[ ] Integrate PR with osrm-frontend (to see what breaks)
[ ] Code review
[ ] Update the changelog
[ ] Make sure that relevant docs are updated
[ ] Release as new version 0.3
[ ] Update osrm-frontend to use 0.3

CC @freenerd

This PR looks like it’ll address #106.

I tried to integrate these changes into osrm-frontend, but that failed. The reason is browserify, which we use to bundle the required() js files. Dynamic requires are not supported https://github.com/substack/node-browserify/issues/377 and there doesn't seem to be a way to specify which files to required upfront.
I'm good with actually walking back on the requirement of https://github.com/Project-OSRM/osrm-text-instructions/issues/106 to select which language files to load, given it makes bundling of js files so hard for browsers. For the server-side, this isn't actually a big problem, since the memory required is marginal. We should definitely keep switching languages during compile though.


RPi 3 Raspbian / ARM uname_arch_check failing

Moved from https://github.com/goreleaser/godownloader/issues/59
pi@ha:~ $ uname -a
Linux ha 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
pi@ha:~ $ curl https://htmltest.wjdp.uk | bash -s -- v0.9.1-rc1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9929  100  9929    0     0  43803      0 --:--:-- --:--:-- --:--:-- 43740
wjdp/htmltest crit uname_arch_check 'armv7l' got converted to 'arm7' which is not a GOARCH value.  Please file bug report at https://github.com/client9/shlib

Looking at my generated script armv7 is in the list of supported GOARCH values, but arm7 is not.

weird sorry I missed this.  We'll fix it up tomorrow!

fixed!