Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 07 17:30
    HeroicKatora synchronize #1638
  • Dec 07 16:48
    HeroicKatora synchronize #1638
  • Dec 07 16:47
    HeroicKatora opened #1638
  • Dec 07 06:39
    paolobarbolini commented #1637
  • Dec 06 20:50
    fintelia commented #1637
  • Dec 06 09:07
    paolobarbolini edited #1637
  • Dec 06 09:07
    paolobarbolini opened #1637
  • Dec 04 23:40

    fintelia on master

    Add rustfmt::skip annotations Run cargo fmt Enforce formatting via CI and 1 more (compare)

  • Dec 04 23:40
    fintelia closed #1636
  • Dec 04 22:03
    fintelia commented #1636
  • Dec 04 22:01
    fintelia synchronize #1636
  • Dec 04 21:55
    fintelia commented #1636
  • Dec 04 21:12
    fintelia synchronize #1636
  • Dec 04 20:59
    fintelia synchronize #1636
  • Dec 04 20:04
    HeroicKatora closed #1618
  • Dec 04 20:04

    HeroicKatora on master

    Fix image-rs#1618: bmp::decoder… Simplify bmp::decoder::copy_fro… Merge pull request #1635 from a… (compare)

  • Dec 04 20:04
    HeroicKatora closed #1635
  • Dec 04 19:06
    alichay synchronize #1635
  • Dec 04 18:13
    fintelia review_requested #1636
  • Dec 04 18:12
    fintelia opened #1636
HeroicKatora
@heroic_katora:matrix.org
[m]
And a Fuzz-OS that could do this more precisely without the overhead
In any case, regarding CI failure, feel free to bump the minimum rustc version to 1.48
5225225
@r522:matrix.org
[m]
okay cool
CI now passes and i added a short note in the readme about fuzzing
HeroicKatora
@heroic_katora:matrix.org
[m]
Nice, thank you so much for that :)
5225225
@r522:matrix.org
[m]
and hopefully the turnaround for my PRs can only get faster from here :D
one thing that might be worth doing is getting a sample of known valid images and testing that we do parse them fine
because all fuzzing can really do is test that we don't panic on bad input
1 reply
but always returning Err even for valid input would be invisible to the fuzzer
HeroicKatora
@heroic_katora:matrix.org
[m]
As an experience report the turnaround will be slow and fast, depending on mood 😂
It's also far more likely that Issues are opened for erroneous errors than for pathological cases.
And we can more easily throw a fuzzer run in than run against the vastness of images on the internet.
5225225
@r522:matrix.org
[m]
heads up HeroicKatora : ravif 0.7.0 has been yanked so cargo check on a clean checkout of image-rs/image doesn't build, bumping it to 0.8.0 looks to work fine
can make a PR to do that bump if you want
HeroicKatora
@heroic_katora:matrix.org
[m]
Sure, feel free to do.
Do you happen to know why it was yanked? Not that it really matters if the bump is a clean one to do
5225225
@r522:matrix.org
[m]
no idea
no mention of it in the issue tracker
there is a yank mentioned because it didn't build, but i'm assuming 0.7.0 built fine
HeroicKatora
@heroic_katora:matrix.org
[m]
Yeah, although a weird reason to yank. It always required a pretty precise/recent version of nasm to build so maybe that's a nudge to use the correct version
5225225
@r522:matrix.org
[m]

image-rs/image#1564

bumped it from 0.7.0 to 0.8.0, and marked the issue about it as Fixes:

tests look fine on my side but i'd definitely check if CI has any problems with it

oh wait yeah
avif isn't run by default
okay it's not a clean bump, i just didn't see the error
looks like just a single type changed tho
HeroicKatora
@heroic_katora:matrix.org
[m]
Ah well, that's still good.
5225225
@r522:matrix.org
[m]
the afl-fuzz target doesn't compile on CI
but i can't seem to reproduce that locally
HeroicKatora
@heroic_katora:matrix.org
[m]

error: failed to run LLVM passes: unknown pass name 'sancov'

Huh, I guess something about the new pass manager in nightly?

5225225
@r522:matrix.org
[m]
unless it's very new
i'll try updating my nightly and trying again
HeroicKatora
@heroic_katora:matrix.org
[m]
Yeah, that one is very new
Like 3 days old
5225225
@r522:matrix.org
[m]
looks to be unfixed upstream
HeroicKatora
@heroic_katora:matrix.org
[m]
Heh, the afl library also moved on 7 versions since it was last updated.
I've only been using the rust-fuzz target :)
(libfuzzer/cargo-fuzz) I mean
5225225
@r522:matrix.org
[m]
yep
i don't know if it's worth keeping around afl if we already use libfuzzer
not used afl but if it's not significantly better at finding stuff, we could remove it?
HeroicKatora
@heroic_katora:matrix.org
[m]
Yeah, I was considering the same just now. Let me try just bumping to latest and if that works I'll PR it quickly.
And forcibly merge :)
Which I'll do for the ravif one as well
5225225
@r522:matrix.org
[m]
cool
i have a fix for image-rs/image#1501 in a draft PR, just running the fuzzer for a bit to see if it finds any other issues, then I'll open up the PR (image-rs/image#1563)
5225225
@r522:matrix.org
[m]

also, thoughts on adding limits to jpeg-decoder?

https://github.com/image-rs/jpeg-decoder/blob/ab6d326a7b194568725731a19603fb580814452d/src/decoder.rs#L277 is at least one source of unbounded allocation, but I saw discussion on trying to make it library-wide image-rs/image#938.

HeroicKatora
@heroic_katora:matrix.org
[m]
So the library wide version is 'advisory' first and it's not necessary to implement for decoders. We're still looking for real world feedback if it's okay to reject some of the image formats if a limit is requested (I mean, there is no version with it released so far..).
On limits for jpeg in particular, sure, yeah. It would be cool to have it in 0.2
It's probably quite huge of a thing to thread through all the code though. So it would be interesting to first evaluate if the interface allows adding it and fix any issues there, and only then actually add it incrementally afterwards.
Jacob Mischka
@jacobmischka:matrix.org
[m]
I'm trying to convert a vec of bytes of unknown format (via with_guessed_format) to a new vec of bytes in JPEG format. The resulting images are viewable and the correct size, but incomplete, the bottom half or so is just grey. Am I doing something obvious wrong?
Sorry for lack of details, I'm walking and on mobile at the moment. I can provide more in a little bit when I'm back at my desk.
I'm flushing the writer that I'm ultimately using to write those bytes, so I don't think that is the issue. But I could be wrong of course.
I'm just doing this to write to the vec
let mut bytes: Vec<u8> = Vec::new();
// read data to end from incoming stream
let img = ImageReader::new(Cursor::new(bytes)).decode()?;
let mut bytes: Vec<u8> = Vec::new();
img.write_to(&mut bytes, image::ImageOutputFormat::Jpeg(90))?;
er, hm sorry I don't seem to know how to insert code via mobile obviously
HeroicKatora
@heroic_katora:matrix.org
[m]
That looks correct to me. Have you tried decoding it to a raw image with jpeg-decoder crate directly?
Or utilizing its example/decode.rs. If the image there still shows up with a grey portion then we'd appreciate a bug report.
Please be sure to try out older versions of the repository as well (the git commit of the version you're depending on currently would be best).
Jacob Mischka
@jacobmischka:matrix.org
[m]

:point_up: Edit: I'm just doing this to write to the vec

let mut bytes: Vec<u8> = Vec::new();
// read data to end from incoming stream
let img = ImageReader::new(Cursor::new(bytes)).decode()?;
let mut bytes: Vec<u8> = Vec::new();
img.write_to(&mut bytes, image::ImageOutputFormat::Jpeg(90))?;

```

Jacob Mischka
@jacobmischka:matrix.org
[m]
Sorry, false alarm, it was the way I was writing it out
Thanks for your response, and thanks for your work on the library!