Re: [PATCH] [GSOC] ref-filter: solve bugs caused by enumeration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 于2021年5月6日周四 下午7:20写道:
>
> ZheNing Hu <adlternative@xxxxxxxxx> writes:
>
> >> So the fix was to see what atom it is by checking its name member?
> >> Is starts_with() a reliable test?  A fictitious atom "pushe" will be
> >> different from "push" or "push:<something>", but will still pass
> >> that test, so from the point of view of future-proofing the tests,
> >> shouldn't it do the same check as the one at the beginning of
> >> remote_ref_atom_parser()?
> >>
> >
> > I think it's not necesssary. Before we call `populate_value()`, ...
>
> I do not care if it is not needed with the "current" set of atoms we
> accept.  The example "pushe", which obviously will not be accepted
> by today's code, was all about future-proofing.

Well, what you said makes sense, now I think something like this will be
more secure. In the future, other people may be grateful for such a choice. :)

@@ -1730,7 +1759,7 @@ static int populate_value(struct ref_array_item
*ref, struct strbuf *err)
                        else
                                v->s = xstrdup("");
                        continue;
-               } else if (starts_with(name, "push")) {
+               } else if (starts_with(name, "push") &&
atom->u.remote_ref.push) {


--
ZheNing Hu




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux