sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: AsFd impl for Stdout/StdoutLock can violate locking guarantees of those types.
Labels: T-libs-api,C-bug,A-io

The stdout/err APIs guarantee that they're globally synchronized:

> Each handle returned is a reference to a shared global buffer whose access is synchronized via a mutex. If you need more explicit control over locking, see the [Stdout::lock](https://doc.rust-lang.org/nightly/std/io/struct.Stdout.html#method.lock) method.

This can be relied on to write whole lines at a time, e.g. for json-lines style logging where multiple threads shouldn't interleave their output. It can be ok if some random other library or thread outputs non-JSON output, but it's important that it's not emitted in the middle of a line that's currently being emitted.

The combination of  `impl AsFd for Stdout`, `try_clone_to_owned()` and `impl From<OwnedFd> for File` can then be used to break that guarantee. `AsRawFd` is somewhat less of an issue because any use of the created `RawFd` should be unsafe.

Possible solutions:

- weaken the guarantees
- deprecate or remove the impls
- add "don't do that" warnings


Related: https://github.com/rust-lang/libs-team/issues/148#issuecomment-1650566584 and following.
Repository: kubernetes
Issue: NCC-E003660-MRE: API Server Proxy Disables TLS Certificate
Labels: sig/api-machinery,sig/security,triage/accepted

### NCC-E003660-MRE: API Server Proxy Disables TLS Certificate
Validation
This issue was reported in the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Impact**
An attacker suitably positioned on the network may be able to intercept TLS connections
being made to pods, services or nodes from the API server proxy.

**Description**
When the proxy functionality in the Kubernetes API server is used, the TLS certificate for
the pod, service or node being accessed will not be checked by the API server. This could
allow an attacker suitably positioned on the network to intercept the TLS connection to
read or modify the traffic. The level of risk this presents will depend on the network
architecture of a particular cluster.

Note that this discussion refers to the connection made by the API server to the pod,
service or node which is the target of the proxy connection. The connection from the
client to the API Server is not affected by this issue.

For an example, please see the original finding on page 29 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Recommendation**
Consider whether it is possible to implement TLS certificate validation for pod, service and
node proxying. This would require a means of specifying the expected server certificate or
trust store.

If this is not possible, ensure that documentation for the relevant APIs makes it clear that
these connections are potentially vulnerable to man-in-the-middle attacks.

**Component**
kube-apiserver

**Location**
Function `CreateProxyTransport()` in file [release-1.24 server.go:L224](https://github.com/kubernetes/kubernetes/blob/release-1.24/cmd/kube-apiserver/app/server.go#L224-L234)

**Anything else we need to know?**
See umbrella issue [#118980](https://github.com/kubernetes/kubernetes/issues/118980) for current status of all issues created from these findings.
The vendor gave this issue an ID of NCC-E003660-MRE and it was finding 8 of the report under the kube-apiserver section.
The vendor considers this issue Medium Risk, High Impact, Low Exploitability
To view the original finding, begin on page 29 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Test Environment**
Kubernetes 1.24.3
Repository: kubernetes
Issue: NCC-E003660-7HM: EmptyDir Volumes Do Not Support Mount Options
Labels: sig/storage,kind/feature,sig/security,needs-triage

### NCC-E003660-7HM: EmptyDir Volumes Do Not Support Mount Options
This issue was reported in the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

It should be noted that this issue has previously been reported in [issue #48912](https://github.com/kubernetes/kubernetes/issues/48912).

**Impact**
An attacker able to execute code inside a pod with a mounted emptyDir volume would be
able to load arbitrary files, including malicious tooling, into this directory and use them to
launch further attacks.

**Description**
Pod volumes can use a volume of type emptyDir, providing a directory that can be shared
between all the images in a pod or provide a predictable location regardless of the
container image directory structure. These volumes are commonly used to provide a
scratch space or to share files between multiple containers in a pod.

The emptyDir volume provider does not currently support specifying mount options such
as `nosuid` or `noexec`. As a result, it is not possible to create a writable space for use as
scratch storage which disables execution of files stored in that space. Kubernetes users
following best practices often create pods using a read-only root filesystem in an attempt
to hinder any attackers able to compromise a running container. Creating an emptyDir
volume that is writable is often used to provide a location for logs, or as temporary storage
for applications that require write access for operational purposes.

As a specific risk example, by not allowing an emptyDir volume to be created with the
`noexec` flag set, administrators are forced to accept an additional risk.

**Recommendation**
Allow emptyDir volumes to be mounted with the `noexec` flag.

**Component**
kube-apiserver

**Anything else we need to know?**
See umbrella issue [#118980](https://github.com/kubernetes/kubernetes/issues/118980) for current status of all issues created from these findings.
The vendor gave this issue an ID of NCC-E003660-7HM and it was finding 9 of the report under the kube-apiserver section.
The vendor considers this issue Low Risk, Low Impact, Low Exploitability
To view the original finding, begin on page 32 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Test Environment**
Kubernetes 1.24.3
Repository: kubernetes
Issue: NCC-E003660-47W: Loopback Token Usable Externally
Labels: priority/backlog,sig/auth,sig/security,triage/accepted

### NCC-E003660-47W: Loopback Token Usable Externally
This issue was reported in the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Impact**
If an external attacker were able to obtain the API server’s loopback token, they could use
it to obtain access with `system:masters` privileges.

**Description**
The Kubernetes API server creates an ephemeral “loopback token” at initialization time.
This is assigned to the `system:apiserver` user, and is a member of the `system:masters`
group. It is used by the API server to authenticate when making calls to its own services on
the loopback interface. However, there are no checks in place to ensure that requests
using this token have arrived on the loopback interface, or that they originate from
localhost. It should be noted that no method for an attacker to acquire the loopback token
in order to use it externally was identified - adding these checks is recommended only as a
useful additional layer of defense in depth.

**Recommendation**
Add checks to ensure that the loopback token is only accepted for authentication on the
API server’s loopback interface.

**Component**
kube-apiserver

**Anything else we need to know?**
See umbrella issue [#118980](https://github.com/kubernetes/kubernetes/issues/118980) for current status of all issues created from these findings.
The vendor gave this issue an ID of NCC-E003660-47W and it was finding 11 of the report under the kube-apiserver section.
The vendor considers this issue Low Risk, High Impact, Undetermined Exploitability
To view the original finding, begin on page 33 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Test Environment**
Kubernetes 1.24.3
Repository: vscode
Issue: Git - "Upstream already exists" when creating a fork
Labels: bug,git


Type: <b>Bug</b>

1. Clone a repository that you don't own.
2. Make changes and commit.
3. Push, expect error and accept "create a fork."

"Upstream already exists" error occures. It looks like vscode is trying to rename "origin" to "upstream", but by default it adds and fetches the upstream remote if origin is a fork.

VS Code version: Code 1.80.1 (74f6148eb9ea00507ec113ec51c489d6ffb4b771, 2023-07-12T17:22:07.651Z)
OS version: Windows_NT x64 10.0.22621
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 7 4800H with Radeon Graphics          (16 x 2895)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|15.36GB (4.51GB free)|
|Process Argv|. --crash-reporter-id 37e3d3c0-0353-49c0-a3ec-ac3bf4ecb544|
|Screen Reader|no|
|VM|0%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
3biah626:30602489
89544117:30613380
2i9eh265:30646982
showlangstatbar:30737416
vsctsb:30748421
03d35959:30757346
pythonfmttext:30731395
pythoncmvfstrcf:30756944
fixshowwlkth:30771522
showindicator:30785052
pythongtdpath:30769146
i26e3531:30792625
gsofa:30797621
pythonnosmt12:30797651
pythonnoceb:30797650
e537b577:30795824
dsvsc013:30795093
dsvsc014:30797589

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: cmd/dist: fails with buildvcs=false errors if invalid .git exists in parent of GOROOT_BOOTSTRAP
Labels: NeedsInvestigation

Related: #54852 - cc @williamh @bcmills

In Buildroot we have a build failure when there exists an invalid .git in a parent directory of GOROOT_BOOTSTRAP: https://gitlab.com/buildroot.org/buildroot/-/jobs/4725186525

```
Building Go toolchain1 using /builds/buildroot.org/buildroot/test-output/TestMender/host/lib/go-1.19.10.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
go tool dist: FAILED: /builds/buildroot.org/buildroot/test-output/TestMender/host/lib/go-1.19.10/bin/go install -tags=math_big_pure_go compiler_bootstrap purego bootstrap/cmd/...: exit status 1
```

Reproduction of the issue:

```
# This reproduction sets up a directory structure that breaks Go make.bash.
# make.bash should not break due to .git files outside of the Go sources.
#
# The error specifically occurs when an invalid .git is present in a parent git
# directory of the GOROOT_BOOTSTRAP. Go issue #61620
mkdir go-issue-61620
cd ./go-issue-61620
wget https://go.dev/dl/go1.19.11.src.tar.gz
mkdir go-bootstrap
tar -xf go1.19.11.src.tar.gz -C ./go-bootstrap --strip-components=1
cd ./go-bootstrap/src/
bash make.bash
cd ../../
wget https://go.dev/dl/go1.20.6.src.tar.gz
mkdir go
tar -xf go1.20.6.src.tar.gz -C ./go/ --strip-components=1
printf "gitdir: ../../does/not/exist/.git" > ./.git
cd ./go/src/
GOROOT_BOOTSTRAP=$(pwd)/../../go-bootstrap/ bash make.bash
# Build fails using -buildvcs=false errors.
```

The error only occurs when the .git that git detects in the parent directory
of the GOROOT_BOOTSTRAP is invalid or not present causing errors when running `git` commands within GOROOT_BOOTSTRAP.
Repository: pytorch
Issue: `torch.ops.aten.split.Tensor._schema` return alias annotations are wrong
Labels: triaged,module: viewing and reshaping

The schema of `split.Tensor` is:
```
split.Tensor(Tensor(a -> *) self, SymInt split_size, int dim=0) -> Tensor(a)[]
```

where the output is a TensorList with the same alias annotation as the input (`a`).

It looks like `torch.ops.aten.split.Tensor`'s schema info doesn't capture this information:
```
>>> torch.ops.aten.split.Tensor._schema.returns[0].alias_info.before_set
set()
>>> torch.ops.aten.split.Tensor._schema.arguments[0].alias_info.before_set
{'a'}
>>> torch.ops.aten.split.Tensor._schema.arguments[0].alias_info.after_set
{'*'}

# This should return {'a'}, probably?
>>> torch.ops.aten.split.Tensor._schema.returns[0].alias_info.before_set
set()
>>> torch.ops.aten.split.Tensor._schema.returns[0].alias_info.after_set
set()
```
Repository: react-native
Issue: URL and URLSearchParams is not working
Labels: Issue: Author Provided Repro,Needs: Triage :mag:

### Description

I was working with React Native and I needed to parse a URL to get a parameter, for that I used the `URL` class and got the serialized `searchParams`, but in every attempt it gave all kinds of errors.

```js
const url = new URL('https://somesite.com/?search=param')

console.log(url.searchParams.get('search')) //  Throw 'URLSearchParams.get is not implemented'
console.log(url.searchParams.toString()) // ''
```

### React Native Version

0.72.3

### Output of `npx react-native info`

info Fetching system and libraries information...
System:
  OS: Linux 5.4 Linux Mint 20 (Ulyana)
  CPU: (2) x64 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
  Memory: 304.14 MB / 1.92 GB
  Shell:
    version: "5.8"
    path: /usr/bin/zsh
Binaries:
  Node:
    version: 18.12.1
    path: /usr/local/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.yarn/bin/yarn
  npm:
    version: 8.19.2
    path: /usr/local/bin/npm
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
IDEs:
  Android Studio: Not Found
Languages:
  Java:
    version: 11.0.19
    path: /usr/bin/javac
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.3
    wanted: 0.72.3
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

### Steps to reproduce

1 - Clone the repo
2 - Install its dependecies
3 - Run the project using your favorite platform
4 - Try to input some url

### Snack, screenshot, or link to a repository

https://github.com/natanfeitosa/RNUrlBugReport
Repository: vscode
Issue: Polyglot Notebooks get code cells that are not editable
Labels: under-discussion,notebook-layout

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.81.0-insider (user setup)
- OS Version: Windows_NT x64 10.0.22621

Steps to Reproduce:

1. Install Polyglot notebook
2. create a black notebook
3. add a second cell
The second cell is a single line and not usable, see screenshot of the notebook and webdeveloper tools
![image](https://github.com/microsoft/vscode/assets/375556/faf166b3-4c24-4616-bcd2-0997f67bc7e9)
Repository: flutter
Issue: Don't send app lifecycle events unless there's a listener
Labels: a: desktop,P2,team-framework,triaged-framework

## Repro steps

On macOS:

1. Using a locally built engine, run the [spinning square example](https://github.com/flutter/flutter/blob/master/examples/layers/raw/spinning_square.dart) or any app that doesn't use the widgets layer
2. Hide/show the window a few times

You'll see the following errors in the console:

```
> flutter run --local-engine host_debug_unopt -d macos  ./raw/spinning_square.dart
flutter: A message on the flutter/lifecycle channel was discarded before it could be handled.
This happens when a plugin sends messages to the framework side before the framework has had an opportunity to register a listener. See the ChannelBuffers API documentation for details on how to configure the channel to expect more messages, or to expect messages to get discarded:
  https://api.flutter.dev/flutter/dart-ui/ChannelBuffers-class.html
The capacity of the flutter/lifecycle channel is 1 message.
```

## Solution

We shouldn't send `flutter/lifecycle` messages unless the Dart app has a listener for that channel.

* [x] Windows: https://github.com/flutter/flutter/issues/131616
* [ ] macOS

/cc @gspencergoog
Repository: puppeteer
Issue: [Docs]: docs say that testing Chrome Extension content scripts isn't supported
Labels: feature

### Feature description

The Chrome Extension docs say that testing popup scripts and content scripts is currently not supported, but that's not true since Chrome for Testing and headless: 'new' were announced.

Maybe we should update them to say that support is experimental instead of unsupported?

If this makes sense, I'd be glad to make a PR
Repository: tensorflow
Issue: Support for asynchronous execution in TensorFlow DLPack interface
Labels: stat:awaiting tensorflower,type:feature,comp:apis

I would like to inquire about the possibility of adding asynchronous execution support to the TensorFlow DLPack interface.
Currently, the `tensorflow.experimental.dlpack.to_dlpack` and `tensorflow.experimental.dlpack.from_dlpack` functions are synchronous operations, which can introduce synchronization overhead when working across frameworks.

If the TensorFlow DLPack interface supported asynchronous execution, it could help reduce the synchronization overhead and improve the overall execution efficiency when working with multiple frameworks. This would be a valuable addition to the TensorFlow ecosystem.

Thank you for your hard work and dedication to improving TensorFlow. I look forward to hearing your thoughts on this matter.

### Standalone code to reproduce the issue

```python
import tensorflow as tf
import tensorflow.experimental.dlpack as tfdlpack

# Pre-frame processing asynchronous
...

# Handle synchronization across frameworks
output = model(**({'input': tfdlpack.to_dlpack(input)}))

# Framework post-processing asynchronous
...
```


### Relevant log output

_No response_
Repository: kubernetes
Issue: NCC-E003660-WV3: Privilege Escalation via `nodes/proxy` Permission
Labels: kind/documentation,sig/node,sig/auth,lifecycle/stale,sig/security,needs-triage

### NCC-E003660-WV3: Privilege Escalation via `nodes/proxy` Permission
This issue was reported in the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Impact**
A user with permissions on the `nodes/proxy` subresource in a cluster has full permissions
against the kubelet API on any node by proxying requests through the API server, and can
execute commands in any pod. This may represent privileges beyond those expected by
the cluster administrator, and this situation is not explained in the Kubernetes
documentation.

**Description**
The Kubernetes API server proxy is a feature which allows users to proxy requests through
the API server to workloads or nodes. When a proxy request is made to the kubelet service
on a node, the API server’s own client certificate (which in a typical cluster is a user in the
`system:masters` group) is used to authenticate the request. This effectively allows a user with `get` permissions against the `nodes/proxy` subresource to make `GET` requests to the kubelet
API as `system:masters` (and equivalent for `create`, `patch`, etc.). It is not clear from the
Kubernetes documentation that giving a user permission to make proxied requests to nodes is effectively permitting them to run arbitrary commands against any pod (as can be achieved using the Kubelet API’s `/exec` endpoint).

**Recommendation**
Ensure that the Kubernetes documentation makes it clear that permissions on the `nodes/
proxy` subresource are powerful, overriding other permissions against nodes (as shown
above) and permitting commands to be run in pods.

**Component**
kubelet


**Anything else we need to know?**
See umbrella issue [#118980](https://github.com/kubernetes/kubernetes/issues/118980) for current status of all issues created from these findings.
The vendor gave this issue an ID of NCC-E003660-WHE and it was finding 18 of the report under the kube-apiserver section.
The vendor considers this issue Medium Risk, High Impact, Low Exploitability
To view the original finding, begin on page 49 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Test Environment**
Kubernetes 1.24.3