- Go 88.7%
- PLpgSQL 6.9%
- TypeSpec 4.2%
- Shell 0.2%
e65fbe1d8d* reader: bounds-check r.pos and currentRange.PartNo in getPartReader
getPartReader indexes r.ranges and r.parts directly without any
length guard:
currentRange := r.ranges[r.pos]
partId := r.parts[currentRange.PartNo].ID
r.ranges and r.parts can drift - a user-visible byte range is
computed from the request, but r.parts is populated from storage at
a different moment, and a stale currentRange.PartNo then indexes
past the end of r.parts. The result is a runtime panic
panic: runtime error: index out of range [5] with length 1
internal/reader/reader.go:136 (getPartReader)
that kills the stream goroutine mid-download and shows up as random
crashes in production (#553).
Validate r.pos against len(r.ranges) and currentRange.PartNo against
len(r.parts) before dereferencing, returning a plain error so the
HTTP handler responds with a 500 instead of the server tipping over.
No behaviour change on any well-formed request; only the
inconsistent-state branch changes from panic to error.
Fixes #553
* reader: compare currentRange.PartNo in int64 to avoid 32-bit overflow
int(currentRange.PartNo) on a 32-bit architecture can truncate large
PartNo values down into the len(r.parts) range, letting the bounds
check pass and the subsequent index panic anyway. Compare as int64
against int64(len(r.parts)) instead. Raised by gemini-code-assist
on #565.
Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
---------
Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
Co-authored-by: SAY-5 <SAY-5@users.noreply.github.com>
|
||
|---|---|---|
| .github | ||
| .opencode | ||
| .vscode | ||
| cmd | ||
| docs | ||
| internal | ||
| openapi | ||
| pkg | ||
| scripts | ||
| tests | ||
| typespec | ||
| ui | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| .ogen.yml | ||
| AGENTS.md | ||
| config.sample.toml | ||
| config.sample.yml | ||
| CONTRIBUTING.md | ||
| gen.go | ||
| go.mod | ||
| go.sum | ||
| goreleaser.dockerfile | ||
| LICENSE | ||
| main.go | ||
| README.md | ||
| Taskfile.yml | ||
| tspconfig.yaml | ||
| VERSION | ||
Teldrive
Teldrive is a powerful utility that enables you to organise your telegram files and much more.
Advantages Over Alternative Solutions
-
Exceptional Speed: Teldrive stands out among similar tools, thanks to its implementation in Go, a language known for its efficiency. Its performance surpasses alternatives written in Python and other languages, with the exception of Rust.
-
Enhanced Management Capabilities: Teldrive not only excels in speed but also offers an intuitive user interface for efficient file interaction which other tool lacks. Its compatibility with Rclone further enhances file management.
Important
Teldrive functions as a wrapper over your Telegram account, simplifying file access. However, users must adhere to the limitations imposed by the Telegram API. Teldrive is not responsible for any consequences arising from non-compliance with these API limits.You will be banned instantly if you misuse telegram API.
Visit https://teldrive-docs.pages.dev for setting up teldrive.
Recognitions
Best Practices for Using Teldrive
Dos:
- Follow Limits: Adhere to the limits imposed by Telegram servers to avoid account bans and automatic deletion of your channel.Your files will be removed from telegram servers if you try to abuse the service as most people have zero brains they will still do so good luck.
- Responsible Storage: Be mindful of the content you store on Telegram. Utilize storage efficiently and only keep data that serves a purpose.
Don'ts:
- Data Hoarding: Avoid excessive data hoarding, as it not only violates Telegram's terms.
By following these guidelines, you contribute to the responsible and effective use of Telegram, maintaining a fair and equitable environment for all users.
Contributing
Feel free to contribute to this project.See CONTRIBUTING.md for more information.
Donate
If you like this project small contribution would be appreciated Paypal.