sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: crypto/tls: dynamically reload root certificate authorities
Labels: Proposal,Proposal-Crypto

### Proposal Details

The current state of the `tls.Config.RootCAs` presents a challenge when it comes to dynamically reloading the Root Certificate Authorities. The existing approaches involve either disabling automatic certificate and host verification or limiting functionality to non-proxied requests. This proposal seeks to address this limitation by introducing a mechanism for dynamic reloading of Root CAs.

The current workaround for dynamically updating Root CAs involves using the `VerifyPeerCertificate`, but it requires disabling automatic certificate and host verification by setting the `InsecureSkipVerify` field to true. This approach might introduce some security risks if the custom implementation is not correct.

Alternatively,  a custom TLS Dialer could be used. However, this approach falls short when dealing with proxied requests, limiting its applicability in scenarios where proxies are used.

To enhance the flexibility of TLS configurations, this issue proposes modifying the behaviour of `tls.Config.RootCAs` to support dynamic reloading by introducing a function similar to `GetClientCertificate`.

Note that in the past, a similar [request](https://github.com/golang/go/issues/22836) was rejected. Since commenting on that issue is disabled, I decided to create a new issue to see if something has changed. Having such a mechanism in the standard library would help the Kubernetes community address https://github.com/kubernetes/kubernetes/issues/119483.

Update:

It largely depends on how the `tls.Config.RootCAs` is used internally. Another solution would be to accept an interface instead of `*x509.CertPool` and allow clients to inject a thread-safe implementation, enabling trust reloading.
Repository: stable-diffusion-webui
Issue: [Bug]: Cannot find torch version 2.0.1 when running webui-user.bat on Windows 10
Labels: asking-for-help-with-local-system-issues

### Checklist

- [ ] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [X] The issue has been reported before but has not been fixed yet

### What happened?

When I run webui-user.bat on Windows 10 it will start to install torch and torchvision but is unable to find the version 2.0.1 of torch.
Other issues related to this from what I have seen were on another OS and was a memory issue but my allocated Vmemory (12800mb) is much above my recommended (3958mb).

### Steps to reproduce the problem

1. Go to installation of stable-diffusion-webui
2. Run webui-user.bat

### What should have happened?

Torch should have been installed and the rest of the install should have continued.

### What browsers do you use to access the UI ?

Other

### Sysinfo

(im so sorry, was having trouble figuring out how to run sysinfo command)
Windows 10 Home Version 22H2
GPU: AMD Radeon RX 6600 XT
Processor: AMD Ryzen 5 3600 6-Core Processor 3.60 GHz
RAM: 24.0 GB


### Console logs

```Shell
Python 3.12.1 (tags/v3.12.1:2305ca5, Dec  7 2023, 22:03:25) [MSC v.1937 64 bit (AMD64)]
Version: v1.7.0
Commit hash: cf2772fab0af5573da775e7437e6acdca424f26e
Installing torch and torchvision
Looking in indexes: https://pypi.org/simple, https://download.pytorch.org/whl/cu118
ERROR: Could not find a version that satisfies the requirement torch==2.0.1 (from versions: none)
ERROR: No matching distribution found for torch==2.0.1
Traceback (most recent call last):
  File "C:\ai\stable-diffusion-webui\launch.py", line 48, in <module>
    main()
  File "C:\ai\stable-diffusion-webui\launch.py", line 39, in main
    prepare_environment()
  File "C:\ai\stable-diffusion-webui\modules\launch_utils.py", line 378, in prepare_environment
    run(f'"{python}" -m {torch_command}', "Installing torch and torchvision", "Couldn't install torch", live=True)
  File "C:\ai\stable-diffusion-webui\modules\launch_utils.py", line 116, in run
    raise RuntimeError("\n".join(error_bits))
RuntimeError: Couldn't install torch.
Command: "C:\ai\stable-diffusion-webui\venv\Scripts\python.exe" -m pip install torch==2.0.1 torchvision==0.15.2 --extra-index-url https://download.pytorch.org/whl/cu118
Error code: 1
Press any key to continue . . .
```


### Additional information

_No response_
Repository: PowerToys
Issue: Support Kannada language
Labels: Idea-Enhancement,Issue-Translation

### Description of the new feature / enhancement

Support Kannada language

### Scenario when this would be used?

Some people want to use this but don't know English, add this language.

### Supporting information

_No response_
Repository: storybook
Issue: [Bug]: yarn build errors in latest SB example code
Labels: bug,cli,typescript,sev:S2

### Describe the bug

Standard SB install in a fresh react-ts-vite environment, running the default yarn build (build": "tsc && vite build",) produces this in your example code

```
yarn build
src/stories/Button.tsx:1:1 - error TS6133: 'React' is declared but its value is never read.

1 import React from 'react';
  ~~~~~~~~~~~~~~~~~~~~~~~~~~

src/stories/Header.tsx:1:1 - error TS6133: 'React' is declared but its value is never read.

1 import React from 'react';
  ~~~~~~~~~~~~~~~~~~~~~~~~~~

src/stories/Page.tsx:15:8 - error TS2375: Type '{ user: User | undefined; onLogin: () => void; onLogout: () => void; onCreateAccount: () => void; }' is not assignable to type 'HeaderProps' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
  Types of property 'user' are incompatible.
    Type 'User | undefined' is not assignable to type 'User'.
      Type 'undefined' is not assignable to type 'User'.

15       <Header
          ~~~~~~
```

### To Reproduce

It is your pre-canned example source. 

To fix remove the React imports and change to this in Header.tsx

interface HeaderProps {
    user?: User | undefined;


### System

```bash
...or yarn dlx storybook@latest info

Storybook 7.6.5 for react-vite started
```


### Additional context

For completeness 

"typescript": "^5.3.3",
        "vite": "^5.0.8",
Repository: vscode
Issue: Investigate importing CAs from SystemRootCertificates.keychain
Labels: feature-request,proxy

> `Mac CA VSCode` additionally reads the CAs from `'/System/Library/Keychains/SystemRootCertificates.keychain'`. I will investigate if that would make sense to add by default. 

 _Originally posted by @chrmarti in [#541](https://github.com/microsoft/vscode-copilot-release/issues/541#issuecomment-1862526542)_
Repository: rust
Issue: std::process::Command does not work properly with less privileged children accessing stdin/stdout/stderr file descriptors
Labels: C-bug,T-libs,O-unix,A-process

I tried this code:

```rust
use std::io::Write;
use std::os::unix::process::CommandExt;
use std::process::{Command, Stdio};

fn main() {
    let mut command = Command::new("/bin/cat");
    command.arg("/dev/fd/0")
        .stdin(Stdio::piped())
        .stdout(Stdio::piped())
        .stderr(Stdio::piped())
        .uid(35565)
        .gid(35565);

    let mut child = command.spawn().unwrap();
    child.stdin.take().unwrap().write_all("foo".as_ref()).unwrap();
}
```
<details><summary>Tokio version:</summary>
<p>

```rust
use std::process::Stdio;

use tokio::io::{AsyncReadExt, AsyncWriteExt};
use tokio::process::Command;

#[tokio::main]
async fn main() {
    tokio::task::spawn(async move {
        let mut command = Command::new("/bin/cat");
        command.arg("/dev/fd/0")
            .stdin(Stdio::piped())
            .stdout(Stdio::piped())
            .stderr(Stdio::piped())
            .uid(35565)
            .gid(35565);

        let mut child = command.spawn().unwrap();
        child.stdin.take().unwrap().write_all("foo".as_ref()).await.unwrap();
    });
}
```

</p>
</details>


I expected to see this happen:
The child process opens and reads it's stdin.

Instead, this happened: 
The child process was unable to read it's stdin fd.

### Meta

I've asked around about this issue in other places and it seems that it's Linux quirk that the Rust standard library does not handle. Neither does there seem to be a proper way to handle it (nor do I know how to safely work around stdlib).

* https://superuser.com/a/1699427
* https://github.com/tokio-rs/tokio/issues/6193
* https://users.rust-lang.org/t/letting-child-process-read-stdin-after-dropping-privileges/90860

`rustc --version --verbose`:
```
rustc 1.74.1 (a28077b28 2023-12-04)
```
Repository: rust
Issue: rustc starts describing trait bounds and pointing at complicated library internals instead of just saying to add #[derive(Clone)]
Labels: A-diagnostics,T-compiler,D-confusing,D-newcomer-roadblock

### Code

```Rust
#[derive(Clone)]
enum Necessity<T> {
    Optional(T),
    Mandatory(T),
}

struct Element<T> {
    attributes: Vec<Necessity<T>>,
    children: Vec<Necessity<Element<T>>>,
}

impl<T: std::clone::Clone> Element<T> {
    fn clone(&self) {
        let _ = self.children.clone();
    }
}

fn main() {
    println!("Hello, world!");
}
```


### Current output

```Shell
Compiling rust_issue v0.1.0 (/home/seeb/rust/rust_issue)
error[E0599]: the method `clone` exists for struct `Vec<Necessity<Element<T>>>`, but its trait bounds were not satisfied
   --> src/main.rs:14:31
    |
2   | enum Necessity<T> {
    | ----------------- doesn't satisfy `Necessity<Element<T>>: Clone`
...
14  |         let _ = self.children.clone();
    |                               ^^^^^ method cannot be called on `Vec<Necessity<Element<T>>>` due to unsatisfied trait bounds
    |
   ::: /home/seeb/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:396:1
    |
396 | pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> {
    | ------------------------------------------------------------------------------------------------ doesn't satisfy `Vec<Necessity<Element<T>>>: Clone`
    |
    = note: the following trait bounds were not satisfied:
            `Necessity<Element<T>>: Clone`
            which is required by `Vec<Necessity<Element<T>>>: Clone`
help: consider annotating `Necessity<Element<T>>` with `#[derive(Clone)]`
    |
2   + #[derive(Clone)]
3   | enum Necessity<T> {
    |

For more information about this error, try `rustc --explain E0599`.
error: could not compile `rust_issue` (bin "rust_issue") due to previous error
```


### Desired output

```Shell
help: consider annotating `Element<T>` with `#[derive(Clone)]`
    |
7   + #[derive(Clone)]
8   | struct Element<T> {
    |
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

_No response_
Repository: go
Issue: x/tools/gopls: Postfix complete supports ordinary functions
Labels: FeatureRequest,gopls,Tools

### gopls version

14.2

### go env

```shell
unimportant
```


### What did you do?

unimportant

### What did you expect to see?

Now gopls already support postfix complete, which is very useful in some scenarios, but these all provides pre-defined.
Some completion is just some ordinary functions.
- for string：split, join
- for slice: len, append

In fact, we do not need to pre-define these functions, just need to search for all the first parameter types according to the type of `X` in `X.Sel`, and then match the name of `Sel`.
For example, the following program s, all functions in `strings` should appear in completion.  
```go
var s string
s.|    // complete: HasSuffix, Split, ContainsRune, ...
```
This feature is useful for some basic types, such as string, slice, map. There are also places to pack different implement using functions, such as Context.Context types.

For some types, these completions may cause disturb, so it should have a relatively low priority.

### What did you see instead?

unimportant

### Editor and settings

_No response_

### Logs

_No response_
Repository: material-ui
Issue: [base-ui][material-ui] Uncontrolled RadioGroup component do not fully reset when inside a <form> with a reset button
Labels: component: radio,package: material-ui,package: base-ui,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example without using state: https://codesandbox.io/p/sandbox/agitated-bogdan-dx9dvn

Link to live example using state: https://codesandbox.io/p/sandbox/brave-chandrasekhar-3h9gdv

### Current behavior 😯

When using Radio Group component, Pressing the reset button in a form does not revert value of the Radio Group to its default value.

If I use Radio Group with state then it will work properly.

### Expected behavior 🤔

Changes in the value of the Radio Group will get reset while clicking on the reset button when we are not using the state (for the first codesandbox).

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (120.0.2210.77)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.28
    @mui/core-downloads-tracker:  5.15.1
    @mui/material: ^5.15.1 => 5.15.1
    @mui/private-theming:  5.15.1
    @mui/styled-engine:  5.15.1
    @mui/system:  5.15.1
    @mui/types:  7.2.11
    @mui/utils:  5.15.1
    @types/react: ^18.2.45 => 18.2.45
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.9.5 => 4.9.5
```
</details>
Repository: kubernetes
Issue: Support longer (maybe pseudo-permanent?) Service Session Affinity
Labels: sig/network,kind/feature,triage/accepted

### What would you like to be added?

According to our session affinity timeout docs: https://kubernetes.io/docs/reference/networking/virtual-ips/#session-stickiness-timeout if timeout is not specified we set it to 3 hours by default: https://pkg.go.dev/k8s.io/api/core/v1#ClientIPConfig

So if we do:
```
  sessionAffinity: ClientIP
```
it is auto converted into:
```
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
```

So currently it seems there cannot be a session affinity without a timeout. Why was it designed this way? Can we change this to support being able to express affinity without timeout or permanent affinity? Maybe we do 
`service.Spec.SessionAffinityConfig.ClientIP.TimeoutSeconds = 0` to convey its permanent session affinity? However not sure if that becomes an API backwards incompatible change since `0` is not allowed as of today as a value.

/sig network

### Why is this needed?

IoT Edge use case where clients send sparse packets but still want to hit the same backend. Users should not have to worry about the timeout being max a day, they should have a way to say "permanent affinity".
Repository: storybook
Issue: Storybook doesn't work with vue-property-decorator
Labels: bug,vue3

### What version of `vite` are you using?

5.0.4

### System info and storybook versions

Storybook v7.6.5

### Describe the Bug

Console error: "Internal server error: Cannot read properties of undefined 
(reading 'get')"

Demo: https://codesandbox.io/p/devbox/priceless-hill-mprrmm?file=%2Fsrc%2Fstories%2FButton.vue%3A12%2C1

 File: /workspaces/workspace/src/stories/Button.vue
      at getArgFromDecorator (/workspaces/workspace/node_modules/vue-docgen-api/src/utils/getArgFromDecorator.ts:12:14)
      at classDisplayNameHandler (/workspaces/workspace/node_modules/vue-docgen-api/src/script-handlers/classDisplayNameHandler.ts:17:18)
      at <anonymous> (/workspaces/workspace/node_modules/vue-docgen-api/src/utils/execute-handlers.ts:74:63)
      at step (/workspaces/workspace/node_modules/.pnpm/@rollup+plugin-typescript@11.1.0_rollup@3.20.2_tslib@2.5.0_typescript@4.9.5/node_modules/tslib/tslib.es6.js:147:23)
      at Object.next (/workspaces/workspace/node_modules/.pnpm/@rollup+plugin-typescript@11.1.0_rollup@3.20.2_tslib@2.5.0_typescript@4.9.5/node_modules/tslib/tslib.es6.js:128:53)
      at <anonymous> (/workspaces/workspace/node_modules/.pnpm/@rollup+plugin-typescript@11.1.0_rollup@3.20.2_tslib@2.5.0_typescript@4.9.5/node_modules/tslib/tslib.es6.js:121:71)
      at new Promise (<anonymous>)
      at __awaiter (/workspaces/workspace/node_modules/.pnpm/@rollup+plugin-typescript@11.1.0_rollup@3.20.2_tslib@2.5.0_typescript@4.9.5/node_modules/tslib/tslib.es6.js:117:12)
      at <anonymous> (/workspaces/workspace/node_modules/vue-docgen-api/src/utils/execute-handlers.ts:74:53)
      at Array.map (<anonymous>)



### Link to Minimal Reproducible Example

_No response_

### Participation

- [ ] I am willing to submit a pull request for this issue.
Repository: rust
Issue: Weirdly placed derive attributes undesiredly accepted
Labels: T-lang,T-compiler,C-bug,A-proc-macros

Consider this ludicrous code:

```rs
use serde::Serialize;

#[derive(Serialize)]
struct Const<const X: i32>;

#[derive(Serialize)]
struct Struct {
    field: Const<{

        #[serde(absurd, transparent)]
        mod inner {}

        42
    }>,
}
```
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ef6a0f6dcbfb51c62d846e0d93da68aa

Currently this builds.  I think it shouldn't.  Essentially I'm sneaking random stuff into the scope of rustc's idea of where `#[serde]` is allowed and then applying `#[serde]` attributes to some of the random stuff.  Obviously serde doesn't look in there so the misplaced attribute is ignored.

If we think it's the macro's job (serde in this case) to prevent this, then syn ought to have a handy function for "just doing it".  Should we then call this function in every macro?  That seems like an impractical prescription, both because we don't want to be changing every macro, and because not every macro uses syn.

So maybe this is a bug in Rust?  I think you need const generics to do this (since that's how to get the block into the struct definition).I  doubt that when const generics were stabilised this was intended.

But fixing it in Rust would have a backward compatibility problem.  In theory someone might be doing something like this deliberately!  So maybe the check needs to be opt-out?

I think the main points of the rustc built-in "unused attribute" warning are to spot (i) typoed attributes (ii) forgotten `#[derive]`.  This situation can't arise from (i), since the attribute *does* exist.  (ii) could only happen if the inner block contained a whole struct definition that someone was trying to derive on, and probably you'd notice another way since the derive's output would be missing (so the struct wouldn't implement the trait or whatever).  So it doesn't seem a very serious problem, even though I guess *some* macros might have semantics that would encourage a user to try this syntax.

The derive macros in std aren't affected because they cheat: they use compiler magic for their attributes.  I think `Default` is the only one that even has an attribute, and putting `#[default]` next to `#[serde(absurd, transparent)]` *does* produce an error.

Anyway, out of serde, syn, and rust, I have chosen to file this as a ticket against rust.  CC @dtolnay
Repository: material-ui
Issue: [base-ui][material-ui] Uncontrolled Checkbox component do not fully reset when inside a <form> with a reset button
Labels: component: checkbox,package: material-ui,package: base-ui,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example without using state: https://codesandbox.io/p/sandbox/serene-shockley-l3yxnn

Link to live example using state: https://codesandbox.io/p/sandbox/sharp-hamilton-8385kw

### Current behavior 😯

When using Checkbox component, Pressing the reset button in a form does not revert value of the Checkbox to its default value.

If I use Checkbox with state then it will work properly.

### Expected behavior 🤔

Changes in the value of the Checkbox will get reset while clicking on the reset button when we are not using the state (for the first codesandbox).

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (120.0.2210.77)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.28
    @mui/core-downloads-tracker:  5.15.1
    @mui/material: ^5.15.1 => 5.15.1
    @mui/private-theming:  5.15.1
    @mui/styled-engine:  5.15.1
    @mui/system:  5.15.1
    @mui/types:  7.2.11
    @mui/utils:  5.15.1
    @types/react: ^18.2.45 => 18.2.45
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.9.5 => 4.9.5
```
</details>
Repository: material-ui
Issue: [base-ui][material-ui] Uncontrolled Switch component do not fully reset when inside a <form> with a reset button
Labels: component: switch,package: material-ui,package: base-ui,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example without using state: https://codesandbox.io/p/sandbox/eager-rgb-m43d9q

Link to live example using state: https://codesandbox.io/p/sandbox/focused-hellman-z83g9c

### Current behavior 😯

When using Switch component, Pressing the reset button in a form does not revert value of the Switch to its default value.

If I use Switch with state then it will work properly.

### Expected behavior 🤔

Changes in the value of the Switch will get reset while clicking on the reset button when we are not using the state (for the first codesandbox).

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (120.0.2210.77)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.28
    @mui/core-downloads-tracker:  5.15.1
    @mui/material: ^5.15.1 => 5.15.1
    @mui/private-theming:  5.15.1
    @mui/styled-engine:  5.15.1
    @mui/system:  5.15.1
    @mui/types:  7.2.11
    @mui/utils:  5.15.1
    @types/react: ^18.2.45 => 18.2.45
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.9.5 => 4.9.5
```
</details>
Repository: deno
Issue: Next.js websocket webpack-hmr silently fails
Labels: bug,node compat

No error is reported in the browser console or the server.