sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: crypto/tls: incompatibility with Trust Settings in CA certificate
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
golang:latest @ docker

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build114266566=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Standard crypto/tls library is incompatible with CA certificates (either root or intermediate one) when they contain Trust Settings (https://www.openssl.org/docs/manmaster/man1/x509.html#TRUST_SETTINGS):
<pre>
$ openssl -in rootCA.crt -text -noout
...
No Trusted Uses.
No Rejected Uses.
Alias: XXX
...
</pre>

Since widely used MS AD-based CAs DO have such Settings in their certs, it is hard to use encrypted connections in golang programms in such environments.


### What did you expect to see?
The successfull TLS-handshake.


### What did you see instead?
In our case server's cert is issued by intermediate CA which is issued by root CA and `server.crt` contains server's cert followed by the intermediate CA's one.

In the case when the Trust Settings are present in the intermediate's cert, tls-negotiation fails with the following errors:
client.go:40: tls: failed to parse certificate from server: asn1: syntax error: trailing data
server.go:55: remote error: tls: bad certificate

If only the root's cert contains the Settings, the errors are slightly different:
client.go:40: x509: certificate signed by unknown authority
server.go:55: remote error: tls: bad certificate

(Example client&server apps are available at https://github.com/kruftik/go-tls-vs-windows-ad-ca, build.sh prepares binaries)

Once the Settings are being stripped from both root and intermedia CA certs with the `openssl x509 -in rootCA.crt -out rootCA.clean.crt` command, the problem is going away.
Repository: create-react-app
Issue: Add support for SRI (Subresource Integrity)
Labels: issue: proposal,tag: enhancement

SRI used to be supported in CRA (facebook/create-react-app#1176) but it was removed because of some incompatibilities (facebook/create-react-app#1231). 

Could we re-add SRI support in CRA? I feel like the reasons given in #1231 could be solved.
Repository: rust
Issue: Infinite "recursive requirements" compiler error
Labels: E-hard,A-diagnostics,A-trait-system,P-medium,T-compiler,C-bug

When compiling this program, the compiler fails with an infinitely recursive error message. The message makes no sense, as it contains types that aren't even in the program.

    use std::ops::{Add, Sub};

    struct Point2d<T> {
        pub x: T,
        pub y: T,
    }

    impl<'a, T> Sub<&'a Point2d<T>> for &'a Point2d<T>
    where &'a T: Sub<&'a T, Output=T>,
    {
        type Output = Point2d<T>;
        fn sub(self, other: &'a Point2d<T>) -> Self::Output { unimplemented!();  }
    }

    fn f1<'a, I>(x: &'a I)
    where &'a I: Sub<Output=I> {   unimplemented!(); }

    fn main() {
        let a = 123;
        f1(&a);
    }

This code won't do anything, but it should compile (I think). Instead, the compiler emits an infinite series of error messages like:

    error[E0275]: overflow evaluating the requirement `&hashbrown::set::HashSet<_, _>: std::ops::Sub`
      --> src\main.rs:28:5
       |
    28 |     f1(&a);
       |     ^^
       |
       = help: consider adding a `#![recursion_limit="128"]` attribute to your crate
       = note: required because of the requirements on the impl of `std::ops::Sub` for `&Point2d<hashbrown::set::HashSet<_, _>>`
       = note: required because of the requirements on the impl of `std::ops::Sub` for `&Point2d<Point2d<hashbrown::set::HashSet<_, _>>>`
       = note: required because of the requirements on the impl of `std::ops::Sub` for `&Point2d<Point2d<Point2d<hashbrown::set::HashSet<_, _>>>>`
       = note: required because of the requirements on the impl of `std::ops::Sub` for `&Point2d<Point2d<Point2d<Point2d<hashbrown::set::HashSet<_, _>>>>>`

This program doesn't even use HashSet.

rustc 1.36.0-nightly (d628c2e64 2019-05-05)
binary: rustc
commit-hash: d628c2e642c6f8f85f24dd5d7f49de89b95bf682
commit-date: 2019-05-05
host: x86_64-pc-windows-msvc
release: 1.36.0-nightly
LLVM version: 8.0
Repository: go
Issue: testing: parallel benchmark results are poorly documented
Labels: Documentation,NeedsFix

The way parallel benchmark results are reported is easy to misinterpret, and the correct way to interpret them is not documented. Typically this makes perfectly-scalable benchmarks appear to perform much worse at low parallelism, and makes not-at-all-scalable benchmarks appear to be doing fine. For example, this came up in https://github.com/golang/go/issues/31820#issuecomment-489112014

Specifically, the "ns/op" reported is not CPU-ns/op, it's wall-ns/op. For example, suppose each op takes exactly 100 ns, regardless of parallelism. If the single-threaded benchmark runs for 1 sec, it will execute 10,000,000 ops, so ns/op = 1s/10,000,000 ops = 100 ns/op. But if the same benchmark runs 4-way parallel for 1 sec, it will execute 40,000,000 ops, so ns/op = 1s/40,000,000 = 25 ns/op. (I really wish it didn't work this way...)

Interpreting the results of CPU-bound parallel benchmarks is further complicated by hyper-threading (though this isn't the fault of the testing package).

I don't think we can change the reported ns/op at this point. We could perhaps introduce a new metric for parallel benchmarks. At the very least, we should document this.
Repository: PowerToys
Issue: X Clipboard (select to copy, middle click to paste)
Labels: Idea-New PowerToy

Select to copy, middle click to paste
Repository: godot
Issue: Refused connection emits connected_to_server on client
Labels: bug,confirmed,topic:network,topic:multiplayer

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
3.1.1-mono


**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->


**Issue description:**
<!-- What happened, and what was expected. -->
connected_to_server was triggered on client when server refused connection.

**Steps to reproduce:**
Start server with refuse_new_connections set to true.
Connect to connected_to_server on a client and let it connect.
Server ignores the connection but the client receives connected_to_server.

**Minimal reproduction project:**
[CustomMultiplayer.zip](https://github.com/godotengine/godot/files/3155612/CustomMultiplayer.zip)
Repository: rust
Issue: Behavior of panicking Drop::drop is not properly documented
Labels: C-enhancement,A-destructors,I-needs-decision,T-lang,A-docs

It was decided in, I think, #14875, that `Drop::drop` can panic, and if this happens, the value must be leaked (at least in a generic context), that is, it cannot be re-dropped again and doing that could invoke UB (that's at least what generic unsafe code needs to assume).

This does not appear to be documented anywhere. These semantics make the following snippet have undefined behavior due to double-drops ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8aa124ceb7a72d954497891d29cf4004) uses `T = Vec<HasDrop>`):

```rust
let mut a: T;
let a_raw = &mut a as *mut  T;

match std::panic::catch_unwind(|| {
    // Drop `a` in place:
    unsafe { std::ptr::drop_in_place(a_raw) };
}) {
    // For exposition only, if the value isn't leaked,
    // it will be re-dropped, but one could also try to 
    // explicitly re-drop on drop failure.
    // UB: this will double-drop some previously dropped fields of a
    Err(_) => std::mem::drop(a),
    // If dropping succeeds, leak a
    Ok(()) => std::mem::forget(a),
}
```

To avoid UB, that snippet must be changed to unconditionally leak the value independently of whether `drop_in_place` succeeded or failed:

```rust
let mut a: T;
let a_raw = &mut *a as *mut T;

std::panic::catch_unwind(|| {
    // Drop `a` in place:
    unsafe { std::ptr::drop_in_place(a_raw) };
});
// Always leak `a`: if dropping failed, some elements will be leaked,
// but there is no way to properly drop them and trying to re-drop
// a could invoke UB
 std::mem::forget(a);
```

---

cc @Centril - this might be a T-lang issue, I don't know the best way to word this, and I can't find any RFC designing this part of the language.
Repository: TypeScript
Issue: `any` appears to shortcircut structural type checking
Labels: Bug,Domain: Conditional Types,Domain: Variance Relationships

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.0-dev.20190507

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
any, unsound, extends, never

**Code**

```ts
// I detect if F is `any` by checking if F extends `never`.
// (F extends never ? true : false) produces `true|false` for `F = any`
// and `false` or `never` for everything else.
type Decider<F> = {
	prop: (F extends never ? true : false) extends false ? "isNotAny" : "isAny";
};

let foo!: Decider<string>;
let bar: Decider<any> = foo;

let fooProp: "isNotAny" = foo.prop;
let barProp: "isAny" = bar.prop;
```

**Expected behavior:**
Either `bar.prop` should have the type `"isAny"|"isNotAny"` or `foo` should not be assignable to `bar`.

**Actual behavior:**
`foo` is assignable to `bar` and `bar.prop` has the type `"isAny"` which is incompatible with `foo.prop`'s `"isNotAny"`.

**Playground Link:** [link](https://www.typescriptlang.org/play/#src=%2F%2F%20I%20detect%20if%20F%20is%20%60any%60%20by%20checking%20if%20F%20extends%20%60never%60.%0D%0A%2F%2F%20(F%20extends%20never%20%3F%20true%20%3A%20false)%20produces%20%60true%7Cfalse%60%20for%20%60F%20%3D%20any%60%0D%0A%2F%2F%20and%20%60false%60%20or%20%60never%60%20for%20everything%20else.%0D%0Atype%20Decider%3CF%3E%20%3D%20%7B%0D%0A%09prop%3A%20(F%20extends%20never%20%3F%20true%20%3A%20false)%20extends%20false%20%3F%20%22isNotAny%22%20%3A%20%22isAny%22%3B%0D%0A%7D%3B%0D%0A%0D%0Alet%20foo!%3A%20Decider%3Cstring%3E%3B%0D%0Alet%20bar%3A%20Decider%3Cany%3E%20%3D%20foo%3B%0D%0A%0D%0Alet%20fooProp%3A%20%22isNotAny%22%20%3D%20foo.prop%3B%0D%0Alet%20barProp%3A%20%22isAny%22%20%3D%20bar.prop%3B)
Repository: TypeScript
Issue: API: expose isReadonlySymbol
Labels: Suggestion,In Discussion,API

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

readonly symbol property

## Suggestion

Expose `isReadonlySymbol` as a method on `TypeChecker`.

Currently there's no way to tell for sure if a property is readonly.
While cumbersome userland implementations can check for `readonly` modifier in `Symbol.declarations`, if it's a GetAccessor without corresponding SetAccessor or if it originated in `Object.definePropery(this, 'propName', {value, writable: false})`.

However, there's one more thing: `Readonly` mapped type only sets `Symbol.checkFlags` which is internal.

So at the very least I need an API to tell if a property's symbol comes from a mapped type with a `readonly` modifier.

/cc @CSchulz you probably need the same API for the lint rule you want to develop.
Repository: flutter
Issue: debugPaint is broken
Labels: framework,f: inspector,platform-web,P3,team-web,triaged-web

If you open the gallery app the debug paint output obscures the entire app:

<img width="1192" alt="Screen Shot 2019-04-23 at 8 38 37 PM" src="https://user-images.githubusercontent.com/211513/56631846-dffbb800-660b-11e9-850c-649b13758134.png">

/cc @jacob314 in case you have more info to share
Repository: flutter
Issue: [Android Web] TalkBack does not read out value changes on increase/decrease. Ex: RangeSlider
Labels: platform-android,framework,a: accessibility,platform-web,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-framework,triaged-framework

TalkBack does not read out value changes on increase/decrease. iOS and Safari correctly read out the announcement.
Repository: flutter
Issue: Add support for fontFamilyFallback in ParagraphStyle and TextStyle
Labels: c: new feature,framework,a: typography,platform-web,e: web_html,P3,team-web,triaged-web

See https://docs.flutter.io/flutter/painting/TextStyle/fontFamilyFallback.html
Repository: flutter
Issue: drawLine paint bounds are overestimated
Labels: engine,c: performance,platform-web,P3,team-web,triaged-web

See screenshot test:

![paint_bounds_for_line_rotated](https://user-images.githubusercontent.com/211513/56527070-f87fab80-6501-11e9-89c1-8207469f5357.png)

See also this TODO: https://github.com/flutter/flutter_web/blob/dcc5b18ee643631cd3c86e3004c380576dfd9c67/packages/flutter_web_ui/lib/src/recording_canvas.dart#L172
Repository: flutter
Issue: TextPainter - forced line-wrapping with bidi in text_painter_rtl_test failing
Labels: a: tests,framework,a: internationalization,a: typography,platform-web,P3,team-web,triaged-web

We are skipping these tests right now.
Repository: flutter
Issue: [Web] Content is missing and misaligned when printing
Labels: c: new feature,framework,a: fidelity,platform-web,P3,team-web,triaged-web

**Describe the bug**
There are multiple issues when attempting to print from the web browser:
- All elements are missing on Safari
- Canvas elements are missing on Chrome
- Content is not centered on Chrome

**To Reproduce**
```
import 'package:flutter_web/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Container(
          color: Colors.white,
          alignment: Alignment.center,
          child: Container(
            height: 100,
            width: 100,
            child: Container(
              color: Colors.black,
              alignment: Alignment.center,
              child: Text('Hello world', style: TextStyle(color: Colors.white)),
            ),
          ),
        ),
      ),
    );
  }
}
```

**Expected behavior**
Printing should behave similarly to traditional HTML web pages.

**Screenshots**
# Page
<img width="494" alt="page" src="https://user-images.githubusercontent.com/2292792/55832861-7a281000-5ae4-11e9-88f0-f85833ea1309.png">

# Chrome
![chrome](https://user-images.githubusercontent.com/2292792/55832875-814f1e00-5ae4-11e9-92d1-ff508f3fcb05.png)

# Safari
![safari](https://user-images.githubusercontent.com/2292792/55832570-d9395500-5ae3-11e9-859b-3ba3376bb401.png)

**Desktop (please complete the following information):**
 - OS: mac
 - Browser chrome 73.0.3683.86, safari 12.0.3
 - Dart Version 2.2.1
 - Flutter Web commit SHA f9288f36fed5f3fda825082ac80f46eec6e7f62f
Repository: angular
Issue: Location shim causes repeat hash in hash-based navigation
Labels: type: bug/fix,freq2: medium,area: router,state: confirmed,P3

When using the `useHash` option for `$locationShim`, routing works until refreshing the browser, at which point the hash appears to be duplicated in the URL. Refreshing again continues to append the hash repeatedly.

Repro: https://github.com/brandonroberts/phonecat-upgrade-cli/tree/840035fcc41d75bbf7b75a494ff40db98f878e7a
Repository: PowerToys
Issue: Moving a program with you to another virtual desktop
Labels: Idea-New PowerToy,Product-Virtual Desktop

One of the thing I've found lacking ever since I started using the virtual desktops is the ability to move a window with you while moving to another virtual desktop.

Currently, we can move to another desktop using the shortcut `ctrl + win + left/right`, I feel like a shortcut along the lines of  `ctrl + win + alt + left/right` could be used to make the current active window move with you to the next desktop

I have no idea if this fits as a powertoy, please tell me if it doesn't !
Repository: pytorch
Issue: ProcessGroupMPI tests in test_c10d.py
Labels: oncall: distributed,module: tests,triaged

These are not in place yet due to the non trivial work required to launch an MPI test.

Go through the test cases in `test_c10d.py` and evaluate where we need to add tests that use `ProcessGroupMPI`. Also figure out where refactoring is needed to support this.

There is an opportunity to consolidate the multi process test harness in `MultiProcessTestCase` between `test_c10d.py` and `test_distributed.py` and make it work for both MPI and non-MPI tests.
Repository: terminal
Issue: Support Right to Left (RTL) text
Labels: Issue-Feature,Help Wanted,Area-Rendering,Product-Terminal

* What you're doing and what's happening: When writing some right-to-left characters (Farsi, Arabic, ...) after some left-to-right characters, the rtl text goes from the cursor position into the left, causing it to be mixed with the ltr text written before.

* Steps to reproduce: Open a Windows Terminal window. write some english characters, like `abcdef`. Then write some Farsi/Arabic text, like:

        سلام

     Notice that the Farsi text goes inside the english text.

* Screenshot:

![image](https://user-images.githubusercontent.com/1775637/57334402-e2463200-7134-11e9-8fc7-656d25e2226d.png)


* what should be happening instead: As console is generally left to right, the rtl text should begin more on the right (cursor should go to right), and it should end exactly when the ltr text ended. See how Notepad (correctly) handles this situation:

![image](https://user-images.githubusercontent.com/1775637/57463000-2ea58500-728f-11e9-8414-21807c52b8a5.png)


* Windows build number:  10.0.18362.86
Repository: terminal
Issue: Feature Request: Ctrl-Drag anywhere on the terminal window to move the window
Labels: Issue-Feature,Area-UserInterface,Product-Terminal

Moving the terminal window around is tricky, particularly when `experimental_showTabsInTitlebar` is enabled.  Many unix terminals (and some Windows console replacements) allow Ctrl-LeftDrag operations on the window to map to a window drag instead.  Would love to see this added to Windows Terminal as well!
Repository: rust
Issue: powerpc64: allow querying ELF ABI version
Labels: T-lang,O-PowerPC

There are two ABIs on ppc64, ELFv1 (legacy) and ELFv2 (introduced a couple years back, used by default for little endian). Rust currently has logic in it that for the `musl` libc, ELFv2 is used on big endian and ELFv1 is used otherwise. This is inadequate, as you can use ELFv2 as well with `glibc`. In my distribution, both little and big endian systems are supported, with `glibc` and `musl`, and they are all set up for ELFv2.

In order to achieve that, Rust in the distribution is patched so that it will always properly use ELFv2 ABI. However, this is a potential problem for some crates that for example need to deal with assembly code; they have no way to query the ABI version. For endianness, they can do like `#[cfg(target_endian = "big")]`. For ABI, there is no equivalent (in C, you can do `#if _CALL_ELF == 2`).

I can look into implementing this, but I need to know what would be the best syntax and way to implement this. As I see it, it would need a new field in the target options, but this would of course be specific to ppc64, and ABI on ppc64 in e.g. gcc is treated more like a list than a string (you can also have `-mabi=altivec`, `-mabi=ibmlongdouble` and so on, in addition to `-mabi=elfv2`), so I was wondering if something more generic/extensible would be better.

Of course, eventually it'd be best to also allow setting it when compiling, and make it properly pass everything down to llvm, but that's less of a concern, for now I just need crates to be able to read it.
Repository: create-react-app
Issue: Syntax error appears twice in console
Labels: issue: bug

1. Create a new project
2. Make a syntax error

The terminal is fine but the console reports the same error twice:

<img width="838" alt="Screen Shot 2019-05-08 at 00 23 36" src="https://user-images.githubusercontent.com/810438/57339054-cbe5a980-7127-11e9-9ee8-e843d2de25ec.png">