C.Y.M wrote: > - setMax(minsize[colorid].y2, yp + len - 1); > + setMax(minsize[colorid].y2, yp); This looks like a minor performance bug fix, as the written area is a horizontal line, not a box. > +static bool OsdMatchesArea(cOsd *osd, tArea &area) This (plus remainings of patch) re-allocates the osd if the new area doesnt fit into the old osd. This may be a bug, if this actually occurs. As far as I understand it, the dvbspu.c translates subpictures to osd bitmaps, though I dont really know who actually uses this. Maybe DVD plugin? The second patch is a security patch, described here: http://www.debian.org/security/2005/dsa-656 > - FILE *f = fopen(FileName, "wb"); > + int fd = open(FileName, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 00640); > + if (fd > -1) { > + FILE *f = fdopen(fd, "wb"); This seems to force creating a new GRAB file with (00640 & ~umask) access rights, while fopen always uses (00666 & ~umask). Additionally, this version fails if the GRAB file already exists. (vdradmin-am wont work with this, as the file is pre-allocated by vdradmin-am. ;) ) I dont agree with this fix, because (1) insecure SVDRP access is IMHO a security hole in any case, (2) if VDR runs properly as restricted user, there shouldnt be any critical files with write access, and (3) though the patched version cannot overwrite existing files, it still can create new files anywhere, and thats IMHO not much better. Cheers, Udo
