sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: End-2-end encrypted kubectl exec using SSH as protocol
Labels: area/security,sig/node,sig/api-machinery,kind/feature,sig/architecture,lifecycle/frozen,triage/needs-information,sig/security

The current kubectl-exec implementation is using the transport encryption from the kubectl to the apiserver and the transport encryption from the apiserver to the kubelet to tunnel the terminal data. The terminal data itself is not protected otherwise, i.e. the apiserver can read everything in plain text.

This is a potential attack surface as taking over the apiserver allows to watch execs and/or to even initiate them to attack any pod and compromise it.

**In other words, this issue is part of the investigation of how containers on the node can be protected if the apiserver cannot be fully trusted.**

The basic idea is:
- use end-2-end encrypted connections from kubectl to the pods for kubectl-exec (and -run and -port-forward)
- using SSH as the binary protocol
- by letting the kubelet spawn ad-hoc SSH servers on each connection
- add an ssh subcommand to kubectl like `kubectl ssh -i ~/.ssh/kube-rsa pod-name /bin/bash`.

The SSH public key will be provided somehow to the kubelet. One approach would be to pass them as an annotation of a pod. But as the apiserver by assumption cannot be trusted, also the annotation cannot be trusted. This means that measures are necessary to protect against the apiserver playing man-in-the-middle by faking the public keys in the pod's annotation. So probably the kubectl needs some kind of identity check that it is talking to the kubelet and no man-in-the-middle.
Repository: go
Issue: encoding/gob: slow map decoding
Labels: Performance

### What version of Go are you using (`go version`)?

go version go1.8 linux/amd64

### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/opennota/gocode"
GORACE=""
GOROOT="/home/opennota/go"
GOTOOLDIR="/home/opennota/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build966707479=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

### What did you do?

I tried to encode a big map to gob

1. as a map.
2. as slices of keys and values

and decode the encoded data back. In the first case the data decodes almost 3x slower.

https://play.golang.org/p/ZpHC-4I9p1


Output:
```
533.188157ms
180.698776ms
```
Repository: TypeScript
Issue: Preserve JSDocs in *.d.ts files when stripping comments
Labels: Suggestion,In Discussion

# Suggestion/Feature
When using the switch ```removeComments``` it will strip out all comments including the ones you may consider useful to the end consumer such as JSDocs. I'd like to strip out any internal comments but preserve any JSDocs comments. It seems that an option to preserve comments in types would be sufficient.

## Existing functionality
```json
"removeComments": true,
"declaration": true,
```
removes all comments including those in *.d.ts files.

## Suggested functionality
```json
"removeComments": true,
"declaration": true,
```
I would think by default you'd want to include the JSDocs in your type defs, so this would remove all comments from the code, but retain any comments associated with the types ie JSDocs.

If however, there is a need to remove all comments then an additional switch may be required to serve that purpose:

```json
"removeCommentsIncludingDeclarations": true,
"declaration": true,
```
Would produce the same result we have today.
Repository: TypeScript
Issue: Can not set static properties on arrow-function-initialized variables
Labels: Bug,Domain: JavaScript

```ts
// @ts-check

const F1 = () => { };
F1.prop = 0; // Error prop does not exist on F

const F2 = function() { };
F2.prop = 0; // OK
```
Repository: flutter
Issue: Custom URL scheme handling
Labels: c: new feature,framework,f: routes,P3,team-framework,triaged-framework

Basically this is a feature request for handling custom URI scheme for inter-app communication within the framework.

The feature itself is pretty straightforward. Would like to provide additional description if necessary.

ref:
- https://developer.android.com/training/basics/intents/filters.html
- https://developer.android.com/training/app-links/index.html
- https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
- https://developer.apple.com/library/content/featuredarticles/iPhoneURLScheme_Reference/Introduction/Introduction.html
Repository: rust
Issue: Tracking issue for spurious network failures on bots
Labels: A-spurious,T-infra,C-tracking-issue,A-CI

I'm hoping to catalog network failures on the bots here just to keep an eye on the rate that they're happening as well as common failure modes. If they're common enough we should investigate solutions.


#### github errors

* https://travis-ci.org/rust-lang/rust/jobs/217835684 - failed to clone repo
* https://travis-ci.org/rust-lang/rust/jobs/217834828 - failed to clone repo

#### Submodule clone timeout

https://travis-ci.org/rust-lang/rust/jobs/210363616

```
Cloning into '/home/travis/build/rust-lang/rust/src/llvm'...

No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.

Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated
```

## Fixed faiulres 

#### Failure to fetch OpenSSL tarball

Fixed by https://github.com/rust-lang/rust/pull/40545

https://travis-ci.org/rust-lang/rust/jobs/211285568

```
curl: (7) Failed to connect to www.openssl.org port 443: Connection refused


command did not execute successfully: "curl" "-o" "/checkout/obj/build/mipsel-unknown-linux-gnu/openssl/openssl-1.0.2k.tar.tmp" "https://www.openssl.org/source/openssl-1.0.2k.tar.gz"
expected success, got: exit code: 7
```


#### CentOS 5 urls changed

https://travis-ci.org/rust-lang/rust/jobs/218179477

hopefully fixed by https://github.com/rust-lang/rust/pull/41045

CentOS 5.11 become EOL, apparently the base image failed to keep succeeding at `yum update`

#### Crates.io errors

Presumed [bug in Cargo](https://github.com/rust-lang/cargo/pull/3890)

* https://travis-ci.org/rust-lang/rust/jobs/214573195 - during cargotest
* https://travis-ci.org/rust-lang/rust/jobs/214511796 - during cargotest
* https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2517/job/78c29lc858e7a0nh - corrupt download?
Repository: rust
Issue: Consider specific warning for trying to use an existing variable in a pattern
Labels: C-enhancement,A-diagnostics,T-compiler

According to the book, this is a common mistake (common enough to call out specifically, anyway):

    fn compare(x: i32, y: i32) {
        match x {
            y => println!("match"),   // wrong
            _ => println!("no match")
        }
    }
    
    fn main() { compare(3, 4); }

Rust currently emits 3 warnings:

* `y` argument is unused
* `y` match-binding is unused
* `_` pattern is unreachable

All are correct. But if this really is a common pitfall, it'd better for Rust to have a specific diagnostic for this problem.

The last two warnings, in combination with the other binding `y` already in scope, strongly suggest that the programmer has made this exact mental mistake. The third warning in particular shows that the programmer expected the pattern `y` to be refutable.

The new warning could be something like: "the identifier `y` in this pattern introduces a new variable (it does not refer to the variable `y` declared *here*)"

(Of course shadowing an existing binding is normal in other circumstances; I'm only proposing a different warning for certain situations where Rust already emits warnings.)
Repository: go
Issue: cmd/link: linker should be able to remove init functions with no side-effects
Labels: binary-size,compiler/runtime

In this example:

`testlinker/a/a.go` 
```go
package a

type DieDieType struct {
	Test map[string]int
}

var DieDieVar = &DieDieType{
	Test: make(map[string]int),
}

var Constant = 5
```

`testlinker/main.go`
```go
package main

import (
	"fmt"
	"testlinker/a"
)

func main() {
	fmt.Println(a.Constant)
}
```

the linker is unable to remove references to `DieDieType` because it is referenced by `a.init`. But this init function, generated by the compiler to initialize `DieDieValue`, is actually useless, because it has no side-effects and only initializes a global variable that is then unreferenced. So the init function could be dropped, and this in turn would remove references to the types.

This is distilled from the analysis in #19523, where just referencing a constant in a package causes a very large growth of binary size because of a deep chain of dependencies which are not used by the program. I haven't fully tracked everything so I can't swear that all init functions are side-effects-free in that case, but I think there's a reasonable chance that it would fix that instance.
Repository: rust
Issue: Derived traits in the standard library are missing stability information
Labels: T-rustdoc,A-stability,T-compiler,C-bug

`impl Default for Duration` was [added in 1.15](https://github.com/rust-lang/rust/pull/37699) but the [current documentation](https://doc.rust-lang.org/std/time/struct.Duration.html) doesn't indicate it wasn't available before that.
Repository: rust
Issue: rustc does not understand linker scripts with `GROUP` statements
Labels: A-linkage,T-compiler,C-bug

I'm statically linking dpdk (`libdpdk.a`) to a rust rlib via Cargo. The compiler fails with `failed to add native library /Volumes/Source/GitHub/lemonrock/dpdk/components/dpdk-sys/compile-dpdk.conf.d/temporary/destdir/usr/local/lib/libdpdk.a: failed to open archive`. This archive is actually a linker script which contains a `GROUP` statement\*. Such linker scripts occur when dealing with native C libraries from time-to-time, particularly on libraries only targeting Linux systems (which have historically used the GNU tools which supported them). I also recall them being used in the past for some ?glibc? .so files.

I'm surprised rustc fails on this - I'd incorrectly assumed it would have just passed the linked argument (`-l static=dpdk`) down to the linker (`cc` in this case). I think rustc should gain some knowledge of these scripts; technically a `GROUP` is supposed to be interpreted as `-Wl,-(` malarky IIRC.

I have a workaround I can implement via a `build.rs` for now, so this isn't critical to me - just open the linker script and spit out the contents to rustc as a bunch of links - but this probably isn't technically correct as I note above. Note, personally, I'm not a fan of linker scripts, but they have their place, I suppose; for those not authoring exotic alternatives to ELF or writing bare metal, they're handy for listing dependencies of dependencies when static linking. I just wish the original authors had used a different file extension for them...

\* FYI, contents of `libdpdk.a`: `GROUP ( librte_acl.a librte_cfgfile.a librte_cmdline.a librte_cryptodev.a librte_distributor.a librte_eal.a librte_efd.a librte_ethdev.a librte_hash.a librte_ip_frag.a librte_jobstats.a librte_kni.a librte_kvargs.a librte_lpm.a librte_mbuf.a librte_mempool.a librte_meter.a librte_net.a librte_pdump.a librte_pipeline.a librte_pmd_af_packet.a librte_pmd_bnxt.a librte_pmd_bond.a librte_pmd_cxgbe.a librte_pmd_e1000.a librte_pmd_ena.a librte_pmd_enic.a librte_pmd_fm10k.a librte_pmd_i40e.a librte_pmd_ixgbe.a librte_pmd_nfp.a librte_pmd_null.a librte_pmd_null_crypto.a librte_pmd_qede.a librte_pmd_ring.a librte_pmd_sfc_efx.a librte_pmd_tap.a librte_pmd_vhost.a librte_pmd_virtio.a librte_pmd_vmxnet3_uio.a librte_port.a librte_power.a librte_reorder.a librte_ring.a librte_sched.a librte_table.a librte_timer.a librte_vhost.a )`
Repository: go
Issue: x/build: make linux-amd64-noopt builder also a pre-submit TryBot
Labels: Builders,NeedsDecision,FeatureRequest

CL 37751 would have benefitted from this.
Repository: vscode
Issue: Add padding when pressing space between a pair of curly braces
Labels: feature-request,editor-autoclosing

When I type `{` to create a pair of curly braces:
```
{}
```
...and then when I press space, I would like 2 spaces to be inserted with the cursor in the middle:
```
{ | }
  ^ cursor
```
Currently it just inserts a single space, so getting the same result requires pressing space twice then the back arrow once. Or otherwise setting:
```
"javascript.format.insertSpaceAfterOpeningAndBeforeClosingNonemptyBrackets": true
// or "typescript.format.insertSpaceAfterOpeningAndBeforeClosingNonemptyBrackets": true
```
...then formatting the line once there's already stuff inside it.

I believe pressing space between a pair of brackets with nothing between them (`{}`) is more-or-less an unambiguous signal (in pretty much any language) that the user intends to have a padding space at both ends. It's also very similar to the already-covered case where someone instead presses enter to produce:
```
{
  | <- cursor
}
```

In Sublime Text I was able to add the functionality myself using a keybinding that looked (in their format) like:
```
{ "keys": ["space"], "command": "insert_snippet", "args": {"contents": " $0 "}, "context":
  [
    { "key": "selection_empty", "operator": "equal", "operand": true, "match_all": true },
    { "key": "preceding_text", "operator": "regex_contains", "operand": "\\{$", "match_all": true },
    { "key": "following_text", "operator": "regex_contains", "operand": "^\\}", "match_all": true }
  ]
}
```
...but in VS Code there doesn't seem to be enough functionality available to add a keybinding like this - I can insert a snippet but can't see anything that would allow me to limit the context to the inside of a pair of brackets.

If someone points me to the place in the codebase where the similar behavior for pressing "enter" is defined, I might be able to open a PR myself.
Repository: youtube-dl
Issue: Allow filtering out payment required videos
Labels: request

cannot download full video of http://www.le.com/ptv/vplay/2061436.html?ch=baiduald_ffdy
this is an vip video, youtube-dl can only download the first 10min of the video .
If cannot download the full video, then this behavior doesn't make much sense, better to remove the behavior .
Repository: youtube-dl
Issue: Add support for TheSurfNetwork
Labels: geo-restricted,account-needed

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.03.10*. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.03.10**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other


### If the purpose of this *issue* is a *site support request* please provide all kinds of example URLs support for which should be included (replace following example URLs by **yours**):
- Single video: http://www.thesurfnetwork.com/watch/75808a1a85aa339c85a5244386e6c82defb4b76458f9675f/trailer
- Single video: http://www.thesurfnetwork.com/detail/75808a1a85aa339c85a5244386e6c82defb4b76458f9675f/movie

---

### Description of your *issue*, suggested solution and other information

I'd like to make a request for thesurfnetwork.com please, thank you. It's account needed and pretty simple to download I think as I can download with Flash Video Downloader extension for Chrome. The reason I asking to download here is when I download with FVD the output file is not the best, but with youtube-dl the output file is perfect!
Repository: neovim
Issue: tui: S8C1T (8-bit) mode, v:termresponse
Labels: enhancement,tui

## Problem

https://github.com/neovim/neovim/issues/25856 implemented `v:termresponse` but we don't yet use it to detect whether we can use 8-bit key sequences.

Related Vim help:

    >       >       >       >       >       >       xterm-8bit xterm-8-bit
    Xterm can be run in a mode where it uses 8-bit escape sequences.  The CSI code
    is used instead of <Esc>[.  The advantage is that an <Esc> can quickly be
    recognized in Insert mode, because it can't be confused with the start of a
    special key.
    For the builtin termcap entries, Vim checks if the 'term' option contains
    "8bit" anywhere.  It then uses 8-bit characters for the termcap entries, the
    mouse and a few other things.  You would normally set $TERM in your shell to
    "xterm-8bit" and Vim picks this up and adjusts to the 8-bit setting
    automatically.
    When Vim receives a response to the t_RV (request version) sequence and it
    starts with CSI, it assumes that the terminal is in 8-bit mode and will
    convert all key sequences to their 8-bit variants.

## Expected behavior

Nvim should detect whether it can use 8-bit mode, via a "request version" `TermResponse` (aka "Primary Device Attributes"?). Unless there's a better way.



## Reference

- Vim in some cases does a synchronous timeout-based check, e.g.: https://github.com/vim/vim/commit/ba6ec182973af726ce9b7b7eb3753fc3a7ae7d1b#diff-366ece1c6e8026aed5df9c6ae82c3967R2622
- [S8C1T mode](http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-C1-_8-Bit_-Control-Characters)
Repository: rust
Issue: rustbuild: if stage0 binaries can't be run, kindly inform user
Labels: T-bootstrap,C-feature-request

Hello!

I was trying to build rust within Alpine linux and since it comes with `musl` instead of `glibc` I've bumped into this confusing error message from rustbuild.

```
$ make check
Traceback (most recent call last):
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 614, in <module>
    main()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 602, in main
    bootstrap()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 587, in bootstrap
    rb.build_bootstrap()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 377, in build_bootstrap
    self.run(args, env)
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 380, in run
    proc = subprocess.Popen(args, env=env)
  File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [Makefile:54: check] Error 1
```

`cargo` is there, in stage0 directory but since it's not compatible with `musl`. execution fails.

My proposal is (thanks @matt36 for the idea) that we should catch the error and inform the user with more context.

```
$ make check
/home/test/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo could not be executed.

You might want to check your internet connection stability since it might be preventing
you from getting stage0 packages correctly.

If the archives are intact, then please check your operating system compatibility on prebuilt 
stage0 binaries. 

Go to: http://docs.rust-lang.org/some/docs/here for more information.

Build completed unsuccessfully in 0:00:00
make: *** [Makefile:54: check] Error 127
```

(If you're wondering "why cargo is not found?" please refer to https://github.com/rust-lang/rust/issues/31322)

Thanks
Repository: TypeScript
Issue: Shorten method signatures (aka "type madness")
Labels: Suggestion,Needs Proposal,Domain: Signature Help,Domain: Type Display

Some of the types that make everything work behind the scenes are ridiculous. For example, from Vue.js:

![image](https://cloud.githubusercontent.com/assets/820883/23925649/7be182ca-08cd-11e7-889b-07e907021dd7.png)

For a Vue developer creating a new Vue instance in JavaScript, they will be exposed to this every time. If they already know what arguments to supply, this does not do a great job as a quick reminder. If they don't know what args to supply, this is probably not very helpful either. We should be able to give users an option to show a _concise_ method signature like the following. 

![image](https://cloud.githubusercontent.com/assets/820883/23926202/140d414a-08d0-11e7-9988-1c81f08af533.png)

In this example, the tildas indicate that there is "type madness" hidden below. If the user really wants to see the types, they can goToDefinition or maybe we could give them a way to expand the signature window. 

We would need to pick some arbitrary line when to display type information and when to hide it. My initial thinking is something along the lines of:
- Hide all generic types, but leave angle brackets in
- Hide types when there are more than 2 unions or intersections
- Show string literals if less than 100 characters (roughly 2 lines?)

I would imagine we would also want to give JavaScript users the concise signature by default and TypeScript users the full signature by default, but give both the camps the ability to configure to their preference.
Repository: rust
Issue: Dyn compatibility error when using an associated type as a type parameter in the super-trait listing
Labels: A-type-system,C-enhancement,A-trait-system,A-associated-items,T-compiler,T-types,A-trait-objects,A-dyn-compatibility

I tried this code:

```rust
trait Super<T> {}

trait Foo: Super<<Self as Foo>::Bar> { type Bar;  }

type BoxFoo = Box<Foo<Bar = u8>>;
```

The code should compile since `Self::Bar` is the type parameter, not `Self`.

Instead, it will fail with the following message:

`the trait Foo cannot be made into an object`
`the trait cannot use Self as a type parameter in the supertrait listing`

FYI [the discussion that sparked this issue](https://www.reddit.com/r/rust/comments/5z3t5j/hey_rustaceans_got_an_easy_question_ask_here/dewgxlf/):

> So this has to do with object safety -- any trait that references Self is not object safe because the true Self type is erased. **However, the error doesn't seem appropriate in this case. I think this warrants a bug report at least to fix the error message, if not to relax the object safety check** (because there could be something I don't see preventing it still... can't say I fully understand object safety).

## Meta

`rustc --version --verbose`: **rustc 1.17.0-nightly (`b1e31766d` 2017-03-03)**
Repository: rust
Issue: Produce a warning when using `const` with interior mutability
Labels: A-lints,T-compiler,C-feature-request

Originally reported in https://users.rust-lang.org/t/broken-atomics-puzzle/9533

Consider this code

```rust
use std::sync::atomic::{AtomicBool, Ordering};

pub const A: AtomicBool = AtomicBool::new(false);

fn main() {
    A.compare_exchange(false, true, Ordering::SeqCst, Ordering::SeqCst);
    println!("A = {}", A.load(Ordering::SeqCst));
}
```
[Playground](https://play.integer32.com/?version=stable&mode=debug&edition=2015&gist=8f714787458e6a0a7eb96591cd0ce6b1)

It compiles and runs cleanly, but produces unexpected results because `const` is used instead of `static`. 

It would be nice to somehow give a warning for `.compare_and_swap` call, but I am not sure it is possible.