michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
indecisiveturtle has quit [Ping timeout: 260 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
Guest73 has joined #ffmpeg-devel
Guest73 has quit [Client Quit]
mkver has quit [Ping timeout: 248 seconds]
\\Mr_C\\ has joined #ffmpeg-devel
<Yalda>
kasper93: left comment on #20025. doesn't look like big deal but wanted to check. ty
<fflogger>
[editedticket] MasterQuestionable: Ticket #11696 ([avformat] WAV ≥ 4 GiB abnormal decoding due to length field overflow) updated https://trac.ffmpeg.org/ticket/11696#comment:4
<Yalda>
I guess the forgejo way to have issue template is having a ISSUE_TEMPLATE.md in the repo (it was simple, but I liked that TRAC had a two line form "Summary of the bug:" and "How to reproduce:")
<Yalda>
I will make MR to have it discussed
<Yalda>
have a local forgejo I can test it with
<BtbN>
You can just test it on your fork on ours
<Yalda>
ha. good point
<BtbN>
the only thing you can't easily test outside of the FFmpeg/FFmpeg repo is the workflows
<Yalda>
this will help since people can click and see it in the discussion. ty
<BtbN>
We also might want to introduce a CODEOWNERS file
<BtbN>
so PRs get auto assigned to the right people
<BtbN>
They need an account first though
\\Mr_C\\ has quit [Remote host closed the connection]
<kasper93>
For testing workflows I recommend GitHub ;p
<kasper93>
Except some specifics it works the same
<kasper93>
Yalda: thanks for review, I responded.
<BtbN>
We have a completely different base image, so no, they behave very differently
<Yalda>
so the CODEOWNERS policy is basically you do not have to be the author of the area but you may be interested in it, upskilling in it, etc and it triggers a review for you? (for example if I am into various random things, demuxers, subtitles)
<Yalda>
I see it at the top of the file. thx
<Yalda>
nvm
<BtbN>
The signing does not survive a rebase, but if certain conditions are met, the instance will then re-sign the commits with its own key
<BtbN>
If all commits were signed with a trusted key already, and the user has 2fa enabled
<BtbN>
So they need a green lock on them, and some person involved needs 2fa enabled. Not sure who exactly
HarshK23 has quit [Quit: Connection closed for inactivity]
GewoonLeon has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
<wbs>
I see some recent mail notifications on ffmpeg-devel from forgejo; are these somewhat permanently set up now, or was that mostly a test? i.e. can one unwatch the repo now, while still seeing an overview of what's happening through the main mail notifications?
<pross>
BtbN: Before merging #20089, forgejo said: 'This commit will be signed with key "/data/gitea/conf/signing_key_ed25519.pub"'. But upon the rebase, it never signed it
<Traneptora>
I'm trying to figureo ut how to approve changes
indecisiveturtle has joined #ffmpeg-devel
futurelugia has joined #ffmpeg-devel
<pross>
Traneptora: the approve button seems only accessible on the 'Files changed' tab with a pull request
<Traneptora>
found it
<Traneptora>
BtbN: are we still required to rebase PRs manually?
<wbs>
Traneptora: it should be possible to do it all from within forgejo now
rvalue has quit [Read error: Connection reset by peer]
<Traneptora>
BtbN: Yalda: the user had the key, but forgejo didn't use their key to sign the commit I pushed to master. I wonder if I need 2FA enabled, since I merged it
rvalue has joined #ffmpeg-devel
<GewoonLeon>
Traneptora: when you rebased it, it got rid of the signature
<Traneptora>
ah, that's what it was
<Traneptora>
figures
indecisiveturtle has quit [Quit: indecisiveturtle]
<BtbN>
The Forgejo maintainers are well aware we're using it
<BtbN>
Traneptora: the built in conditions apparently are "user has a pubkey added to their account" and "user has 2fa enabled"
<BtbN>
and all commits its rebasing need to be signed to begin with, potentially by a trusted contributor
System_Error has quit [Ping timeout: 240 seconds]
<Traneptora>
ah. absent these conditions is there any easy way to preserve the signature other than asking the user to rebase, and then pulling the commit once it's been rebased
<BtbN>
How would you preserve a signature when modifying the commit, without having the private key?
<BtbN>
All it can do is re-sign it with the instance key
<BtbN>
Which also might change the committer
<Traneptora>
well ideally I'd just be not modifying the commit, just cherry-picking it right (commit or commits)
<BtbN>
That is modifying the commit
<BtbN>
its parent and hash changes, which is signed
<Traneptora>
right, so it's not really possible to preserve the signature. someone who applies it to master has to sign it
<Traneptora>
authorship can be preserved, but not author's sig
<BtbN>
If you want it to be signed by the actual author, they have to sign it, and you have to ff-merge it
<Traneptora>
oh so you can with a fast-forward
<BtbN>
yes, rebasing is the problem. If the hash doesn't change, obviously the signature stays
<Traneptora>
so basically what I need to do is to have the author rebase their branch onto master, re-sign the commit, and then once their branch can be fast-forward applied to master, I do that on the CLI and push it, mark it as manually merged
<BtbN>
just hit the FF-Button in the UI
<BtbN>
though manually pushing also works
<BtbN>
Problem with that workflow is, that in the meantime someone else could have merged something, and you need to start over
<Traneptora>
I see, so ultimately the key got stripped by me pushing the "rebase onto master" button on the workflow. the author has to do that (probably locally) to preserve the signature, and then ping me to fast-forward-merge it when they do
<BtbN>
If you'd have rebased it locally, the signatures would have been gone just the same
<BtbN>
you could have re-signed it with your key, making you the committer
<Traneptora>
I see, the author has to do that.
<BtbN>
Who else could? Only they have their own private key
<BtbN>
ideally
<Traneptora>
makes sense, noted for the future
<BtbN>
The instance re-signing them is also fine though imo
<BtbN>
I don't see much harm with modifying the committer, the author should stay the same
System_Error has joined #ffmpeg-devel
GewoonLeon has quit [Quit: GewoonLeon]
GewoonLeon has joined #ffmpeg-devel
<BtbN>
The amount of activity on Forgejo vs. the ML is quite astonishing. Though it's also in "smaller portions" in a sense.
<BtbN>
I've also made the "new ticket" link on Trac redirect to the issues now
<kasper93>
BtbN: have you seen comments about signing not working?
<BtbN>
I've tested signing, and it's working for me
<BtbN>
So some condition must not be fullfilled
<BtbN>
you need a _verified_ pubkey added to your account, and 2fa enabled
<BtbN>
and all commits in a PR need to be already signed. I'm just not sure if by anyone, or if they need a green lock
<kasper93>
I have, didn't work, it also didn't work for pross
<BtbN>
like I said, gotta have to read the code to know details
<BtbN>
It does not say anything specific about that on that page
<kasper93>
it does
<BtbN>
Where?
<kasper93>
in first paragraph, it signs commits that are generated by forgejo, like `Repository initialisation`, `Wiki changes`, `CRUD actions using the web editor or the API` and `Merges from pull requests`
<kasper93>
rebased commits are not generated by forgejo, so they are no signed.
<BtbN>
"Merges from pull requests" is ambiguous though
<kasper93>
It says about auto generated merge commits. Rebase commits are not generated by forgejo.
<nevcairiel>
can some CI jobs run on all requests, if we deem them cheap enough? eg. so that lint can run? or is that an all or nothing?
<BtbN>
pull_request_target and issue triggers run without approcal
<BtbN>
approval
<BtbN>
that's how the one green checkmark happened
<BtbN>
But those also have full write access to the repo, so they need to be used VERY carefully, and not run or interact in dangerous ways with any code
<nevcairiel>
.. and because the jobs are actually inside the repo, its dangerous?
<BtbN>
Those jobs are run from the base branch, so we control the code
<BtbN>
they could of course then go and check out the PR branch, but it's dangerous
<BtbN>
running pre-commit linting would already be problematic, since pre-commit reads its config from within the repo, and will run any python module written in it
<BtbN>
So running that in a workflow with write-permissions is bad news
<nevcairiel>
and i suppose restricted runners is not a thing
<BtbN>
That's not the problem
<BtbN>
those workflows get a token from Forgejo with write access to the repo
<BtbN>
so they could push whatever they like
<nevcairiel>
with restricted i mean that it has no permissions like that
<nevcairiel>
because most jobs dont need it
<BtbN>
No, pull_request_target always has those permissions
<BtbN>
that's why you don't use it except in very special cases
<BtbN>
normal pull_request runs don't have them, so they can safely run in the context of the PR branch
<BtbN>
Like, we only use it for the labeler-task, since it obviously needs to set labels, which needs write-permissions
<BtbN>
Has Nicolas now completely lost his mind?
<nevcairiel>
right, but lint is pull_request, so couldnt it run without a person looking at it first and help to improve PR quality?
<BtbN>
No, cause it loads the linter config from within the PR branch
<BtbN>
Anything that runs code that comes from the PR needs initial manual approval
<nevcairiel>
thats why I always hated having CI setup inside the repo itself, who ever thought that was a good idea
<nevcairiel>
link a second repo to it with just the config or something
<BtbN>
It does make a lot of things a lot easier
<BtbN>
like, adding a new workflow enables it to be tested right there in the PR
<BtbN>
And even if someone runs malicious code in there, the worst they can do is peg the runners CPU to 100% or get itself OOM killed
<cone-361>
ffmpeg Michael Niedermayer release/5.1:67fcbe528c06: avformat/img2dec: Clear padding data after EOF
<cone-361>
ffmpeg Michael Niedermayer release/5.1:722e982fe54e: avformat/wtvdec: clear sectors
<cone-361>
ffmpeg Michael Niedermayer release/5.1:18fcdb860d79: tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content
<cone-361>
ffmpeg Michael Niedermayer release/5.1:c07fe9a3eb78: avformat/wtvdec: Check length of read mpeg2_descriptor
<cone-361>
ffmpeg Michael Niedermayer release/5.1:a79d390d2166: avformat/lmlm4: Eliminate some AVERROR(EIO)
<cone-361>
ffmpeg Michael Niedermayer release/5.1:41cbd7934102: avfilter/vf_xfade_opencl: Check ff_inlink_consume_frame() for failure
<cone-361>
ffmpeg Michael Niedermayer release/5.1:810159a0da93: avfilter/af_surround: Check output format
<cone-361>
ffmpeg Michael Niedermayer release/5.1:cbe80399b812: avfilter/vf_tonemap_opencl: Dereference after NULL check
<cone-361>
ffmpeg Michael Niedermayer release/5.1:4df3cd852fa0: avfilter/vf_v360: Assert that vf was initialized
<cone-361>
ffmpeg Michael Niedermayer release/5.1:b04d1365d367: avfilter/vf_xfade: Compute w2, h2 with float
<cone-361>
ffmpeg Michael Niedermayer release/5.1:428590539ece: avcodec/dxva2: Initialize dxva_size and check it
<cone-361>
ffmpeg Michael Niedermayer release/5.1:4b4b8d45cb55: avcodec/dxva2: Initialize ConfigBitstreamRaw
<cone-361>
ffmpeg Michael Niedermayer release/5.1:7d51c98f02ed: avcodec/dxva2: initialize validate
<cone-361>
ffmpeg Michael Niedermayer release/5.1:234607698040: avcodec/dxva2: initialize hr in ff_dxva2_common_end_frame()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:c9d4fb32cf83: avdevice/dshow: Initialize 2 pointers
<cone-361>
ffmpeg Michael Niedermayer release/5.1:ca38b468d56a: tools/target_dec_fuzzer: Check that FFv1 doesnt leave uninitialized memory in its buffers
<cone-361>
ffmpeg Michael Niedermayer release/5.1:9fb8aec40c59: avcodec/sga: av_assert1 check init_get_bits8()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:027f8d7dcda1: avformat/segafilm: Set keyframe
<cone-361>
ffmpeg Michael Niedermayer release/5.1:13555ae146bd: avcodec/mvha: Clear remaining space after inflate()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:4c46fd973843: avformat/mpeg: Check an avio_read() for failure
<cone-361>
ffmpeg Michael Niedermayer release/5.1:009d2a811339: avcodec/shorten: clear padding
<cone-361>
ffmpeg Michael Niedermayer release/5.1:a4a6a7c670a2: avcodec/vc1dec: Clear mb_type_base and ttblk_base
<cone-361>
ffmpeg Michael Niedermayer release/5.1:29f90ca7079e: avcodec/aic: Clear slice_data
<cone-361>
ffmpeg Michael Niedermayer release/5.1:b1d78733db15: avcodec/alsdec: clear last_acf_mantissa
<cone-361>
ffmpeg Michael Niedermayer release/5.1:730ce561a188: avformat/av1dec: Better fix for 70872/clusterfuzz-testcase-minimized-ffmpeg_dem_OBU_fuzzer-6005782487826432
<cone-361>
ffmpeg Michael Niedermayer release/5.1:942697042021: avcodec/avcodec: Warn about data returned from get_buffer*()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:13e553448d54: avformat/apetag: Check APETAGEX
<cone-361>
ffmpeg Michael Niedermayer release/5.1:684ea8d46bf7: avcodec/vc1_block: propagate error codes
<cone-361>
ffmpeg Michael Niedermayer release/5.1:255fae73224f: avcodec/notchlc: Check bytes left before reading
<cone-361>
ffmpeg Michael Niedermayer release/5.1:9714f17f128a: avformat/argo_brp: Check that ASF chunk header is completely read
<cone-361>
ffmpeg Michael Niedermayer release/5.1:7016a790a425: avcodec/wmavoice: Do not use uninitialized pitch[0]
<cone-361>
ffmpeg Michael Niedermayer release/5.1:01131b822153: avformat/mvdec: Check if name was fully read
<cone-361>
ffmpeg Michael Niedermayer release/5.1:36e303a394e3: avcodec/vc2enc: basic sanity check on slice_max_bytes
<cone-361>
ffmpeg Michael Niedermayer release/5.1:d05bbbd2965e: swscale/swscale: Use unsigned operation to avoid undefined behavior
<cone-361>
ffmpeg Michael Niedermayer release/5.1:2e7a948214e3: swscale/output: Fix undefined integer overflow in yuv2rgba64_2_c_template()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:b409adb80cb6: avformat/mxfdec: More offset_temp checks
<cone-361>
ffmpeg Michael Niedermayer release/5.1:4afe8f448464: avformat/mxfdec: Check timecode for overflow
<cone-361>
ffmpeg Michael Niedermayer release/5.1:625df906c54a: avformat/asf: Check picsize
<cone-361>
ffmpeg Michael Niedermayer release/5.1:40ccf6026850: avcodec/jfdctint_template: use unsigned z* in row_fdct()
<cone-361>
ffmpeg Michael Niedermayer release/5.1:18312a1f017a: avcodec/eacmv: Check input size for intra frames
<cone-361>
ffmpeg Michael Niedermayer release/5.1:6c6ee6d0babd: avcodec/svq3: Check for minimum size input
<michaelni>
does anyone want to backport anything to 6.1 or 7.0 ? if not then i intend to make releases from these 2 branches very soon (7.0 maybe today 6.1 maybe tomorrow)
<TheVibeCoder>
If this wasn't you, your account is compromised. Please contact the admins of this site
<Sean_McG>
hi @michaelni, I noticed the gitweb links from FATE are still pointing to git.vl.o instead of code.ff.o -- was the script update not deployed yet?
<Sean_McG>
errrr I mean git.ff.o not code
<jamrial>
imo that should stay like that for now
GewoonLeon has joined #ffmpeg-devel
mkver has quit [Ping timeout: 245 seconds]
mkver has joined #ffmpeg-devel
jamrial has quit []
jamrial has joined #ffmpeg-devel
<GewoonLeon>
<Lynne> found a webp file which returns einval when lavc decodes it, but decodes fine in browsers
<GewoonLeon>
it looks like starting with commit c33f16db1b it errors, before then it does work
HarshK23 has joined #ffmpeg-devel
<Lynne>
thanks
<Lynne>
mkver: could you take a look at it ^^
<Sean_McG>
GewoonLeon: can you supply that webp to mkver? it might help see what is wrong