the uploads are JANKY as SHIT #1
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: oat/in-the-database-2#1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
there are barely any checks for it
the .sm file can be anywhere other than the root, there can be more than one and it doesnt check if the .sm file is even properly structured
so anyone can upload just a garbage .sm file and itll be published just fine
this is mainly a problem with the parser, the zip .sm searching can be fixed relatively easily but as of now the uploading system is held together by duct tape
file checks:
database checks:
check if theres already a song with the same artist and title(nevermind, bad idea)other checks:
zipbombs shouldnt work, ive looked into how basic zipbombs work and they shouldnt affect itdb2
i ran a 10gb zipbomb on it, and wowee! it errors and crashes
doesnt seem like it does any permanent damage though, only an unhandled "bad archive" error
https://github.com/bones-codes/bombs/raw/master/archives/10GB/10GB.zip.bz2
oh fun!! this error is unsolvable unless i use a different library
that is exactly what im going to do
88fc57d
should have fixed the above error, although im not entirely sure whether its a valid zipill try with a few more zipbombs
it seems to not be that affected, as long as i apply enough ratelimits it shouldnt be possible to do a DoS using zipbombs, as it does sort of increase the memory temporarily
i think i can mark that off as fixed
88fc57da82
does md5 checksum checking and duplicate file prevention