On Mon, Jan 24, 2022 at 05:20:49PM +0000, Job Snijders wrote: > On Mon, Jan 24, 2022 at 04:33:10PM +0100, Claudio Jeker wrote: > > This diff does a few things regarding MFT file and hash sequences: > > > > - it validates the filename early on so that if considered valid it can > > be printed by printf(%s) without problems. > > - it assigns the file type (based on the file extension) early on and no > > longer uses this information when comparing the file hash. > > - Handle unknown files more like a soft error, the file hash still needs > > to match but the content is totally ignored. > > > > In other words it no longer rejects MFTs with unknown files in it. > > Right now rpki-client is very strict in what is accepted and it will > > become an some issue when ASPA is becomming more concrete. > > The valid_filename() function (which was re-factored away last week) was > intended to skip over FileAndHash entries which are not recognized by > that version of the rpki-client instance; precisely to support future > applications of the RPKI such as ASPA. > > https://github.com/openbsd/src/commit/dbcbf675726d8774c0bfc9925bda9c36edcb8a93
It did not really do that because any unknown file was considered invalid and with that the MFT failed to parse. > Requiring any content to be present (and the file's calculated digest to > match with the hash listed on the Manifest) might pose a problem with > our --exclude/--include rsync filter: files of unknown type are not > downloaded. Yes, this is an open issue that I have no great solution right now. Another issue is that these files are not moved to valid/ so a run with -n will fail on the MFT because the file is not present. I try to figure out a solution for these issues. Maybe it is enough to just ignore invalid non-existing files in proc_parser_mft_check(). > I think it would be best to check whether the filename on the manifest > conforms to draft-ietf-sidrops-6486bis, but if it is of an unknown type > to ignore it and not attempt to calculate/compare the hash. The filename still must conform to draft-ietf-sidrops-6486bis. Non-conforming filenames are a hard parse error for the MFT. > Perhaps it is worth expanding the return types from rtype_from_mftfile() > to differentiate between INVALID and UNKNOWN to make this easier? I think we could just rename INVALID to UNKNOWN but I need to double check with the source. I doubt we want both unless there is a really good reason for it. -- :wq Claudio
