mteb/LocBenchRR huggingface dataset:
What to do with "UserWarning: An unhandled message box popped up during your test!"?
There are many of these warnings in the CI logs basically spamming the output and drowning out other more interesting warnings.

These warnings are originating from https://github.com/Open-MSS/MSS/blob/1327ede1dbe3f4eb26bf3889934fa76c74fb428b/conftest.py#L227.

I am not sure why this warning was introduced in the first place, but in my opinion there are two options to handle this better:
1. If it is an issue that there are unhandled message boxes, then this should fail the respective test.
2. If it is not an issue, then we shouldn't flood the output with this warning.

Since I am not too familiar with the internals of the test suite I'd like to discuss how to make this better.
What to do with "UserWarning: An unhandled message box popped up during your test!"?
There are many of these warnings in the CI logs basically spamming the output and drowning out other more interesting warnings.

These warnings are originating from https://github.com/Open-MSS/MSS/blob/1327ede1dbe3f4eb26bf3889934fa76c74fb428b/conftest.py#L227.

I am not sure why this warning was introduced in the first place, but in my opinion there are two options to handle this better:
1. If it is an issue that there are unhandled message boxes, then this should fail the respective test.
2. If it is not an issue, then we shouldn't flood the output with this warning.

Since I am not too familiar with the internals of the test suite I'd like to discuss how to make this better.
Use multi-row inserts for massive speedups on to_sql over high latency connections
I have been trying to insert ~30k rows into a mysql database using pandas-0.15.1, oursql-0.9.3.1 and sqlalchemy-0.9.4. Because the machine is as across the atlantic from me, calling `data.to_sql` was taking >1 hr to insert the data. On inspecting with wireshark, the issue is that it is sending an insert for every row, then waiting for the ACK before sending the next, and, long story short, the ping times are killing me.

However, following the instructions from [SQLAlchemy](http://docs.sqlalchemy.org/en/latest/core/dml.html#sqlalchemy.sql.expression.Insert.values), I changed 

``` python
def _execute_insert(self, conn, keys, data_iter):
    data = [dict((k, v) for k, v in zip(keys, row)) for row in data_iter]
    conn.execute(self.insert_statement(), data)
```

to 

``` python
def _execute_insert(self, conn, keys, data_iter):
    data = [dict((k, v) for k, v in zip(keys, row)) for row in data_iter]
    conn.execute(self.insert_statement().values(data))
```

and the entire operation completes in less than a minute. (To save you a click, the difference is between multiple calls to `insert into foo (columns) values (rowX)` and one massive `insert into foo (columns) VALUES (row1), (row2), row3)`). Given how often people are likely to use pandas to insert large volumes of data, this feels like a huge win that would be great to be included more widely.

Some challenges:
- Not every database supports multirow inserts (SQLite and SQLServer didn't in the past, though they do now). I don't know how to check for this via SQLAlchemy
- The MySQL server I was using didn't allow me to insert the data all in one go, I had to set the chunksize (5k worked fine, but I guess the full 30k was too much). If we made this the default insert, most people would have to add a chunk size (which might be hard to calculate, as it might be determined by the maximum packet size of the server).

The easiest way to do this, would be to add a `multirow=` boolean parameter (default `False`) to the `to_sql` function, and then leave the user responsible for setting the chunksize, but perhaps there's a better way?

Thoughts?
url: private_resolution/dns_resolution useless
### Description
The url.enable_private_resolution and url.enable_dns_resolution settings do not work as advertised, and the concept of the latter is fatally flawed.

The current `url.py` private-address protection logic is as follows:
```python
if not enable_private_resolution:
    if host is ip and ip is private:
        return E_NAUGHTY
    if enable_dns_resolution and resolve(host) is private:
        return E_NAUGHTY
post_title(url)
```
This has many problems, as demonstrated below.

### Reproduction steps
Oh lordy.

#### Scenario 1: Attacker has $2
1. Buy a domain, e.g. `haha.bad`
2. Create a DNS record: `haha.bad A 127.0.0.1`
3. Post a link in IRC: `http://haha.bad/csrf/me/daddy`

If enable_dns_resolution is disabled, this bypasses all private-address protection.

#### Scenario 2: Attacker doesn't have $2
1. Configure webserver to respond to requests with `302 http://127.0.0.1/csrf/me/daddy`
2. Post a link to `http://$webserver_ip/`

The posted link is a public IP, so Sopel will happily load it and follow the redirect to the private address.

#### Scenario 3: Attacker has $2, but the above is fixed
1. Buy a domain, e.g. `haha.bad`
2. Set the nameservers for `haha.bad` to an IP you control
3. Run a script on that IP with the following behavior:
```
attack = False
if attack := not attack:
    return dns_record(type="A", address="1.2.3.4", ttl=0)
return dns_record(type="A", address="127.0.0.1", ttl=0)
```
In the checking stage, Sopel will see the address 1.2.3.4. When performing the request, 127.0.0.1 will be used without validation. ([TOCTOU](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use))

#### Scenario 4: Attacker has $2 and target is IPv6
1. Buy a domain, e.g. `haha.bad`
2. Point `haha.bad` to the target IPv6 address
3. Post a link to `http://haha.bad/csrf/me/daddy`

`dns.resolver.resolve()` does not request AAAA records, so any combination of DNS and IPv6 passes validation.

### Expected behavior
As explained on IRC, this behavior (especially the first two parts) is objectively broken and gives a false sense of security. We should either remove those config options and not pretend, or we should make url.py _unable_ to talk to private IPs.

### Environment
- Sopel `.version`: Since before the name "Sopel" to present.
- Relevant plugins: url.py

### Notes
Ping @dgw and @Exirel, who requested this be an issue instead of IRC comments and a PR.

url: Unexpected error on nonexistent domains
The following code line raises an unhandled `dns.resolver.NXDOMAIN` for URLs at nonexistent domains:

https://github.com/sopel-irc/sopel/blob/eff60e9b49a14e1f3c0c4dab5bb4d2ddbf0098a5/sopel/modules/url.py#L377

Some variant of this operation has been in the code for a while, but the context has changed so much during 8.x that I decided not to follow `git blame` all the way back to the first addition of `dns.resolver`. Seemed like a waste of time.
bincount rejects bool
### Description

[numpy.bincount](https://numpy.org/doc/stable/reference/generated/numpy.bincount.html) accepts bool, but [jax.numpy.bincount](https://jax.readthedocs.io/en/latest/_autosummary/jax.numpy.bincount.html) does not:

```sh
$ py -c "import numpy as np; print(np.bincount(np.ones(3, bool)))"
[0 3]
$ py -c "from jax import numpy as jnp; print(jnp.bincount(jnp.ones(3, bool)))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/carlos/venv/lib/python3.12/site-packages/jax/_src/numpy/lax_numpy.py", line 3068, in bincount
    raise TypeError(f"x argument to bincount must have an integer type; got {_dtype(x)}")
TypeError: x argument to bincount must have an integer type; got bool
```

### System info (python version, jaxlib version, accelerator, etc.)

```
jax:    0.4.35
jaxlib: 0.4.34
numpy:  1.26.4
python: 3.12.7 (main, Oct  1 2024, 02:05:46) [Clang 15.0.0 (clang-1500.3.9.4)]
device info: cpu-1, 1 local devices"
process_count: 1
platform: uname_result(system='Darwin', node='Carloss-MacBook-Pro-2.local', release='23.6.0', version='Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:46 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6031', machine='arm64')
```
Prevent repetitive output to counter BREACH-type attacks
Description
	 
Currently the CSRF middleware sets the cookie value to the plain value of the token. This makes it possible to try to guess the token by trying longer and longer prefix matches. An effective countermeasure would be to prevent repetitive output from appearing in case a guess matches the CSRF prefix.
As it's a prefix-based attack that relies mostly on the server's response, one way to counter it would be to salt the token with a random prefix and when validating discard all but the last n characters of both the cookie and the hidden field value. This would also keep the currently suggested AJAX solution working (JS would just submit the salted value along with the randomized payload).
Prevent repetitive output to counter BREACH-type attacks
Description
	 
Currently the CSRF middleware sets the cookie value to the plain value of the token. This makes it possible to try to guess the token by trying longer and longer prefix matches. An effective countermeasure would be to prevent repetitive output from appearing in case a guess matches the CSRF prefix.
As it's a prefix-based attack that relies mostly on the server's response, one way to counter it would be to salt the token with a random prefix and when validating discard all but the last n characters of both the cookie and the hidden field value. This would also keep the currently suggested AJAX solution working (JS would just submit the salted value along with the randomized payload).
Security issue, unauthorized trusted access by spoofing x-forwarded-for header
**Home Assistant release with the issue:**
0.68.1 but probably older versions too

**Last working Home Assistant release (if known):**
N/A

**Operating environment (Hass.io/Docker/Windows/etc.):**
Hassbian but should be applicable to other deployment methods

**Component/platform:**
http

**Description of problem:**
There is a bug in HA that in certain conditions will allow a person to spoof a trusted source address and bypass password authentication.

Conditions:

- “trusted_networks” is defined with IP values
- “use_x_forwarded_for: True”
- A reverse proxy is used (i.e nginx)
- Attacker can guess one of the IPs in the trusted list (i.e. 127.0.0.1)
- API password is set (or else there is nothing to bypass)

Use case:
Attacker adds a spoofed x-forwarded-for header with an IP that is in the trusted list. HA grants access without asking for a password.

Cause: 
https://github.com/home-assistant/home-assistant/blob/master/homeassistant/components/http/real_ip.py#L22
Uses the first IP in the header which can be spoofed.
Only the last IP in the header is guaranteed to be non-spoofed assuming a valid reverse proxy is in place.

https://en.wikipedia.org/wiki/X-Forwarded-For : Format : 
_“where the value is a comma+space separated list of IP addresses, the left-most being the original client, and each successive proxy that passed the request adding the IP address where it received the request from. In this example, the request passed through proxy1, proxy2, and then proxy3 (not shown in the header). proxy3 appears as remote address of the request.
Since it is easy to forge an X-Forwarded-For field the given information should be used with care. The last IP address is always the IP address that connects to the last proxy, which means it is the most reliable source of information. X-Forwarded-For data can be used in a forward or reverse proxy scenario.”_

**Problem-relevant `configuration.yaml` entries and (fill out even if it seems unimportant):**
```yaml
http:
  # Secrets are defined in the file secrets.yaml
  api_password: !secret http_password
  use_x_forwarded_for: True
  trusted_networks:
    - 127.0.0.1
```

**Traceback (if applicable):**
```

```

**Additional information:**
Work around: Disable trusted_network setting, remove reverse proxy or limit network access to authorized individuals only.

Problem first noticed first by https://community.home-assistant.io/u/NightRanger . Reference: https://community.home-assistant.io/t/trusted-networks-and-x-forwarded-for/20850 

I would issue a PR but I don’t have the right environment to test this. Hopefully somebody who uses this setup can apply the fix and test it.
[Bug]: "Address already in use" for 1 minute after crash (since 0.6.2)
### 🐛 Describe the bug

Since version 0.6.2 (happens also in 0.6.3.post1), after the server dies (due to an exception/crash or hitting ctrl-c), for about a minute, it fails to start again with:
```
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/user/code/debug/.venv/lib/python3.10/site-packages/vllm/entrypoints/openai/api_server.py", line 585, in <module>
    uvloop.run(run_server(args))
  File "/home/user/code/debug/.venv/lib/python3.10/site-packages/uvloop/__init__.py", line 82, in run
    return loop.run_until_complete(wrapper())
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
  File "/home/user/code/debug/.venv/lib/python3.10/site-packages/uvloop/__init__.py", line 61, in wrapper
    return await main
  File "/home/user/code/debug/.venv/lib/python3.10/site-packages/vllm/entrypoints/openai/api_server.py", line 544, in run_server
    sock.bind(("", args.port))
OSError: [Errno 98] Address already in use
```
This prolongs recovery from crashes. In example upon crash Kubernetes immediately restarts the container - previously it would immediately start loading the model again, but now it will do several crash/restart loops until the port is freed.

Verified it happens also with `--disable-frontend-multiprocessing`.

To reproduce it, start vllm with default args, in example:
```
python -m vllm.entrypoints.openai.api_server --model TinyLlama/TinyLlama-1.1B-Chat-v1.0
```
and then send at least one chat or completion request to it (without this it won't reproduce).
then hit Ctrl-C to kill the server.
starting vllm again should throw the "Address already in use" error.
This doesn't happen with vllm <= 0.6.1.

I tried to see why the port is busy, and interestingly the vllm process is dead during this ~1 minute and no other process listens on it. However I noticed that there is a socket open *from* the 8000 port. Can see it via:
```
netstat | grep  ':8000'
```
which would show something like:
```
tcp        0      0 localhost:8000          localhost:40452         TIME_WAIT   -
tcp        0      0 localhost:8000          localhost:56324         TIME_WAIT   -
tcp        0      0 localhost:8000          localhost:40466         TIME_WAIT   -
```
After a minute these entries will disappear and then also vllm will manage to start.
I couldn't attribute it to a PID, nor with various `nestat` or `lsof` flags. Maybe it remains open in the kernel due to unclean process exit?
Klein adds significant performance overhead over a twisted.web server
A minimal hello world benchmark, just routing "/" and returning a string, is half the speed of the equivalent minimal twisted.web server.

I will start investigating where the performance overhead is, and hopefully find some places to optimize.
Sparse output of the changes.
For the `add` and `remove` commands:
Without the `--diff` or `--inline` switch, only the proposed changes should be presented on the screen, with the name of the class the `__repr__` is generated or removed from.
Multi-column Parquet write inefficiencies
Passing along a comment from another developer. " I've noticed that Parquet output from Arkouoda is currently very slow. The Arkouda client library saves multi-column dataframes by sending a separate writeParquet request to the server for each column, adding them to the file one-by-one. The ccp_appendColumnToParquet function doesn't add the column to the file in-place, though; instead it loads the whole existing file into memory, adds the new column to the table object in memory, and overwrites the whole file with the new version. That means it's loading and re-saving the content of all the old columns each time it adds a new one, which adds a lot of overhead since this happens for every column."
Multi-column Parquet write inefficiencies
Passing along a comment from another developer. " I've noticed that Parquet output from Arkouoda is currently very slow. The Arkouda client library saves multi-column dataframes by sending a separate writeParquet request to the server for each column, adding them to the file one-by-one. The ccp_appendColumnToParquet function doesn't add the column to the file in-place, though; instead it loads the whole existing file into memory, adds the new column to the table object in memory, and overwrites the whole file with the new version. That means it's loading and re-saving the content of all the old columns each time it adds a new one, which adds a lot of overhead since this happens for every column."
Any way to get more news?
`ticker.news` seems to return 8 to 10 news articles.

However, Yahoo Finance can offer many more than 8 to 10 news articles per ticker: https://finance.yahoo.com/quote/MSFT/news/ (keep scrolling down).

Is there a way to get more than 8 to 10 news articles with yfinance?
Add "insert_zero" option for np.diff
I often find myself wanting the difference of an array along some axis, where the 0th element should just be the first entry of the array along that axis, so that the shape of the output matches that of the input.   This is a pretty common requirement for people working with finite differences in any way (eg all signal processing)

Currently, I do this with the awkward use of `np.insert`, as demonstrated:

```
a = np.random.RandomState(1234).randint(12, size=(3, 4))
array([[ 3,  6,  5,  4],
       [ 8,  9,  1,  7],
       [ 9, 10, 11, 10]])
# Want a diff along columns of a:
np.diff(np.insert(a, 0, 0, axis=0), axis=0)
> array([[ 3,  6,  5,  4],
       [ 5,  3, -4,  3],
       [ 1,  1, 10,  3]])
# Which is ugly and reallocates a whole intermediate array
# It would be more convenient to go:
np.diff(a, axis=0, insert_zero=True)
```

This would allow us to have an easy inverse of cumsum, so that

`np.all( np.cumsum(np.diff(arr, axis=1, insert_zero=True), axis=1) == arr)`
Image location in Word Document is wrong
### Bug
The image placeholder in parsed docx documents is wrong. An incorrect index is used resulting in a wrong location for images in downstream export formats like markdown.


### Steps to reproduce
Parsing a simple .docx with docling
[image_within_text.docx](https://github.com/user-attachments/files/17919742/image_within_text.docx)


### Docling version
Docling version: 2.7.0
Docling Core version: 2.4.1
Docling IBM Models version: 2.0.6
Docling Parse version: 2.1.2


### Python version
3.12.4


<!-- ⚠️ ATTENTION: When sharing screenshots, attachments, or other data make sure not to include any sensitive information. -->
Raise an error when `len(gligen_images )` is not equal to `len(gligen_phrases)` in `StableDiffusionGLIGENTextImagePipeline`
To whom it may concern,

I found that when using `StableDiffusionGLIGENTextImagePipeline`, there is no error raised when `len(gligen_images )` is not equal to `len(gligen_phrases)`. And when I dig into the source code, it seems that these two features are zipped together in a for loop during the preprocessing. I guess this will cause the longer one to be clipped unintentionally. (If my understanding is wrong, feel free to correct me.) Is there any possibility to raise an error or at least warning? Thanks in advance.

Source Code: https://github.com/huggingface/diffusers/blob/v0.31.0/src/diffusers/pipelines/stable_diffusion_gligen/pipeline_stable_diffusion_gligen_text_image.py#L689
False positive alert on firehose_stream_encrypted_at_rest
### Steps to Reproduce

Hi! There is a bug with the check `firehose_stream_encrypted_at_rest`


### Expected behavior

The check should not alert if the Firehose Server-side encryption (SSE)  is enabled


### Actual Result with Screenshots or Logs

![image](https://github.com/user-attachments/assets/d3ad234f-006b-4293-b780-2c9af652a85a)


### How did you install Prowler?

Cloning the repository from github.com (git clone)

### Environment Resource

Workstation

### OS used

Windows

### Prowler version

Prowler 5.0.0 (You are running the latest version, yay!)

### Pip version

pip 24.2 (python 3.12)

### Context

_No response_
[aDAG][Core] Feeding multiple inputs to aDAG and annotating with TorchTensor does not move tensors to GPU
### What happened + What you expected to happen

When feeding multiple tensors as input to an aDAG, the tensors do not get moved to GPU memory despite annotating with TorchTensor(). The same issue does not occur when only feeding one tensor to the aDAG.

### Versions / Dependencies

Ray==2.34

### Reproduction script

```python
import ray
import torch
import ray.dag
from ray.experimental.channel.torch_tensor_type import TorchTensorType

@ray.remote(num_gpus=1)
class Actor:
    def __init__(self) -> None:
        pass

    def test(self, tensor: torch.Tensor):
        return tensor.device

if __name__ == "__main__":
    ray.init()
    actor1, actor2 = Actor.remote(), Actor.remote()
    with ray.dag.InputNode() as dag_input:
        in1, in2 = dag_input[0], dag_input[1]

        # Dag 1
        in1 = in1.with_type_hint(TorchTensorType())
        in1 = actor1.test.bind(in1)

        # Dag 2
        in2 = in2.with_type_hint(TorchTensorType())
        in2 = actor2.test.bind(in2)

        dag = ray.dag.MultiOutputNode([in1, in2])

    adag = dag.experimental_compile()
    output = ray.get(adag.execute(torch.randn(2, 16), torch.tensor(1.0)))
    print(output)
```


### Issue Severity

Medium: It is a significant difficulty but I can work around it.
DOC: Distinguish between Series.round and Series.dt.round
### Pandas version checks

- [X] I have checked that the issue still exists on the latest versions of the docs on `main` [here](https://pandas.pydata.org/docs/dev/)


### Location of the documentation

https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.Series.round.html#pandas.Series.round

### Documentation problem

When using Series.round, it does not work on date data.

### Suggested fix for documentation

Adding Series.dt.round in the "See also" section would make it more convenient for users to find the relevant documentation.
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.Series.dt.round.html