Open necros2k7 opened 5 years ago
@necros2k7 We really only allow one issue/request..... (I should close it, but.......)
Appveyor/Travis daily build in Releases tab
Elaborate on this, Do the GHA builds not suffice for you?
Update to : libtorrent 2.0.1
WIP
OpenSSL 3
This is still in "ALPHA" Stage.
Apply to https://github.com/google/oss-fuzz
Unsure if this is required/needed.
@thalieht @FranciscoPombal thoughts?
What`s GHA builds?
Github Actions https://github.com/qbittorrent/qBittorrent/actions
Github Actions https://github.com/qbittorrent/qBittorrent/actions
can you point to actual latest binary?
can you point to actual latest binary?
In that list, which is sorted by time, if the middle column says "master" (or first column starts with "Merged pull request...") that is the latest change that was accepted and merged in master branch (which contains all changes since the last release). Every change comes in pairs of 2 lines. Pick the one that doesn't mention "file health", go down to "Artifacts" and dl what you want.
can you point to actual latest binary?
In that list, which is sorted by time, if the middle column says "master" (or first column starts with "Merged pull request...") that is the latest change that was accepted and merged in master branch (which contains all changes since the last release). Every change comes in pairs of 2 lines. Pick the one that doesn't mention "file health", go down to "Artifacts" and dl what you want.
Simply get the newest/latest "master" that will always appear at the top of this list from below link (this excludes the "file health"): https://github.com/qbittorrent/qBittorrent/actions/workflows/ci.yaml?query=branch%3Amaster
qBittorrent-CI_Windows-x64
@necros2k7 This should basically cover all from https://github.com/qbittorrent/qBittorrent/issues/10360#issuecomment-800354697 except for the OSS-Fuzz
request.
The OSS-Fuzz
request is legitimate enough & I would probably suggest to create a "new issue" for that & close this if you are satisfied that your previous needs have been fulfilled?!
@thalieht If necros2k7 creates a "new issue" for the OSS-Fuzz
request we could potentially close #5449 in favour of it?
@thalieht If necros2k7 creates a "new issue" for the OSS-Fuzz request we could potentially close #5449 in favour of it?
I don't know, are they the same thing?
@necros2k7 This should basically cover all from #10360 (comment) except for the
OSS-Fuzz
request.The
OSS-Fuzz
request is legitimate enough & I would probably suggest to create a "new issue" for that & close this if you are satisfied that your previous needs have been fulfilled?!@thalieht If necros2k7 creates a "new issue" for the
OSS-Fuzz
request we could potentially close #5449 in favour of it?
Last time I posted feat.req. for OSS Fuzz on some of my favorite projects - Github tried to ban me for spam, and during week I explained what I meant with techsup., so sorry I can`t make new issue) If anyone likes pls do.
@thalieht If necros2k7 creates a "new issue" for the OSS-Fuzz request we could potentially close #5449 in favour of it?
I don't know, are they the same thing?
OSS fuzz is free service as I undersand and AFL is app, so maybe it can be beneficial to merge these two into something "Fuzzing" named issue
@thalieht
I don't know, are they the same thing?
OSS-Fuzz
currently uses AFL but are replacing/integrating AFL++
Guess we can close the other issue then.
So I guess there is no need in OSSfuzz? Just correct AFL++ setup?
So I guess there is no need in OSSfuzz? Just correct AFL++ setup?
I believe there is a need for it or to at least implement our own parts of what is on offer......
OSSfuzz
also includes sanitizers
(AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer) so I think overall this would be a good idea to look in to more thoroughly indeed.
OSS-Fuzz: Continuous Fuzzing for Open Source Software
Apply to https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/
Fuzz testing
Fuzz testing is a well-known technique for uncovering programming errors in software. Many of these detectable errors, like buffer overflow, can have serious security implications. Google has found thousands of security vulnerabilities and stability bugs by deploying guided in-process fuzzing of Chrome components, and we now want to share that service with the open source community.
In cooperation with the Core Infrastructure Initiative and the OpenSSF, OSS-Fuzz aims to make common open source software more secure and stable by combining modern fuzzing techniques with scalable, distributed execution.
We support the libFuzzer, AFL++, and Honggfuzz fuzzing engines in combination with Sanitizers, as well as ClusterFuzz, a distributed fuzzer execution environment and reporting tool.
Currently, OSS-Fuzz supports C/C++, Rust, Go and Python code. Other languages supported by LLVM may work too. OSS-Fuzz supports fuzzing x86_64 and i386 builds.
Ref: https://github.com/google/oss-fuzz
Sanitizers
This project is the home for Sanitizers: AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer, and more The actual code resides in the LLVM repository. Here we keep extended documentation, bugfixes and some helper code.
The documentation for our tools:
AddressSanitizer (detects addressability issues) and LeakSanitizer (detects memory leaks) ThreadSanitizer (detects data races and deadlocks) for C++ and Go MemorySanitizer (detects use of uninitialized memory) HWASAN, or Hardware-assisted AddressSanitizer, a newer variant of AddressSanitizer that consumes much less memory UBSan, or UndefinedBehaviorSanitizer
Ref:https://github.com/google/sanitizers