pijul_org / pijul

#155 Pijul panics when unrecording an invalid patch

Opened by porglezomp, on August 30, 2017
Closed
porglezomp commented on August 30, 2017

I discovered this when I tried to use a unique prefix instead of a full hash, like in Git.

Version: pijul 0.7.3 (from cargo)

Running pijul unrecord --patch 0 in a repository causes a panic:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:335:20
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: pijul::main
  10: __rust_maybe_catch_panic
  11: std::rt::lang_start
porglezomp commented on August 30, 2017

I've found the issue and am working on a fix. It looks like base64 validation on the command-line isn't done consistently.

lthms commented on August 31, 2017

Good catch! Thanks a lot for reporting this. If you need any help while writing a fix, feel free to ask.

porglezomp commented on September 1, 2017

I've added a base64 validator in the places I could find that needed it, in this patch. (The "Add Patches" button doesn't seem to work?)

pmeunier commented on September 3, 2017

Great patch! I fixed the Nest yesterday for this kind of cases, and merged your patch just now. Thanks!