From: Jonathan A. <jo...@sq...> - 2007-02-02 07:09:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was cleaning up my -users and -devel folders, and stumbled across an email that questioned a security patch. Not the patch itself, but the deployment of it. The user had assumed it'd upgrade his 1.4.8 to 1.4.9a. While this isn't going to happen for a security patch, it did make me start thinking. I was thinking of identifying each patch with a specific code that is unique across versions. I was thinking of a bitwise operation of some sort, along with a deployment script. Take for example, you're running 1.4.9a. The version of your SquirrelMail is 1.4.9a patch L0. We release a security update, which we tag as 1, so your patch level becomes L1. Later we release a second patch which is tagged as 2, so applying both patches takes you to L3. Later we release another patch, which is patch 4. Now if you've been a good SquirrelMail admin, your patch level is now L7. However, say you missed patch 2, your patch level is L5. More details on bitwise operations can be found on wikipedia [1] for those unfamiliar with them. This would make it easy to implement a small script to "check updates" by simply posting the version, and patch level to a website, and it returning the possible security updates. Similar scripts could be used to download a .sqp (really a tarball with a version file, and the patch) and apply the patch, and level to the code. Views? Or should I just go back to bed? - -- Jonathan Angliss <jo...@sq...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFwuL6K4PoFPj9H3MRAmNgAJ9jExDMON0Z+3XbgIcPLjdtHWab2QCg2mdd /r0lUV6ITeQw49tazY6Vd7k= =OMhN -----END PGP SIGNATURE----- |
From: Paul L. <pa...@sq...> - 2007-02-02 20:34:56
|
On 2/1/07, Jonathan Angliss <jo...@sq...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I was cleaning up my -users and -devel folders, and stumbled across an > email that questioned a security patch. Not the patch itself, but the > deployment of it. The user had assumed it'd upgrade his 1.4.8 to > 1.4.9a. While this isn't going to happen for a security patch, it did > make me start thinking. > > I was thinking of identifying each patch with a specific code that is > unique across versions. I was thinking of a bitwise operation of some > sort, along with a deployment script. > > Take for example, you're running 1.4.9a. The version of your > SquirrelMail is 1.4.9a patch L0. We release a security update, which > we tag as 1, so your patch level becomes L1. Later we release a second > patch which is tagged as 2, so applying both patches takes you to L3. > Later we release another patch, which is patch 4. Now if you've been a > good SquirrelMail admin, your patch level is now L7. However, say you > missed patch 2, your patch level is L5. More details on bitwise > operations can be found on wikipedia [1] for those unfamiliar with > them. Sounds like a neat idea, but how would this affect people who are running 1.4.9a (when the current version is, say, 1.4.12) and instead of upgrading, they just take all the security patches that are released and apply them....?? > This would make it easy to implement a small script to "check updates" > by simply posting the version, and patch level to a website, and it > returning the possible security updates. Similar scripts could be > used to download a .sqp (really a tarball with a version file, and the > patch) and apply the patch, and level to the code. > > Views? Or should I just go back to bed? > |
From: Jonathan A. <jo...@sq...> - 2007-02-03 04:24:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On Friday, February 02, 2007, Paul wrote: > On 2/1/07, Jonathan Angliss <jo...@sq...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I was cleaning up my -users and -devel folders, and stumbled across an >> email that questioned a security patch. Not the patch itself, but the >> deployment of it. The user had assumed it'd upgrade his 1.4.8 to >> 1.4.9a. While this isn't going to happen for a security patch, it did >> make me start thinking. >> >> I was thinking of identifying each patch with a specific code that is >> unique across versions. I was thinking of a bitwise operation of some >> sort, along with a deployment script. >> >> Take for example, you're running 1.4.9a. The version of your >> SquirrelMail is 1.4.9a patch L0. We release a security update, which >> we tag as 1, so your patch level becomes L1. Later we release a second >> patch which is tagged as 2, so applying both patches takes you to L3. >> Later we release another patch, which is patch 4. Now if you've been a >> good SquirrelMail admin, your patch level is now L7. However, say you >> missed patch 2, your patch level is L5. More details on bitwise >> operations can be found on wikipedia [1] for those unfamiliar with >> them. > Sounds like a neat idea, but how would this affect people who are > running 1.4.9a (when the current version is, say, 1.4.12) and instead > of upgrading, they just take all the security patches that are > released and apply them....?? We can provide the "scripts" as a small package to download. The patch level can be kept outside of the SQM code, and stored in a .php file. - -- Jonathan Angliss <jo...@sq...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFxA5xK4PoFPj9H3MRAsnYAKCIvYeQ2OxUzphwH4lJYkRBvLe7mwCdGo3X pSWD96rSRWaTcK+3/L/FZGo= =IPNR -----END PGP SIGNATURE----- |
From: Paul L. <pa...@sq...> - 2007-02-04 08:56:26
|
On 2/2/07, Jonathan Angliss <jo...@sq...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Paul, > On Friday, February 02, 2007, Paul wrote: > > On 2/1/07, Jonathan Angliss <jo...@sq...> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> I was cleaning up my -users and -devel folders, and stumbled across an > >> email that questioned a security patch. Not the patch itself, but the > >> deployment of it. The user had assumed it'd upgrade his 1.4.8 to > >> 1.4.9a. While this isn't going to happen for a security patch, it did > >> make me start thinking. > >> > >> I was thinking of identifying each patch with a specific code that is > >> unique across versions. I was thinking of a bitwise operation of some > >> sort, along with a deployment script. > >> > >> Take for example, you're running 1.4.9a. The version of your > >> SquirrelMail is 1.4.9a patch L0. We release a security update, which > >> we tag as 1, so your patch level becomes L1. Later we release a second > >> patch which is tagged as 2, so applying both patches takes you to L3. > >> Later we release another patch, which is patch 4. Now if you've been a > >> good SquirrelMail admin, your patch level is now L7. However, say you > >> missed patch 2, your patch level is L5. More details on bitwise > >> operations can be found on wikipedia [1] for those unfamiliar with > >> them. > > > Sounds like a neat idea, but how would this affect people who are > > running 1.4.9a (when the current version is, say, 1.4.12) and instead > > of upgrading, they just take all the security patches that are > > released and apply them....?? > > We can provide the "scripts" as a small package to download. The > patch level can be kept outside of the SQM code, and stored in a .php > file. OK, but my question is more about what the meaning of patch levels is when the main SM version is older. If L0 starts with SM 1.4.10, and if we start at L0 again with SM 1.4.11, then managing patch levels for SM 1.4.10 beyond the release of SM 1.4.11 is either very ambiguous or quite a lot of maintenance, especially if we do it for every release separately. So if we do the opposite and never reset back to L0, then if there were five levels before 1.4.11 was released, does 1.4.10-L6 imply that only security patches are applied in L6, or is there any other fixes from 1.4.11 included in it from 1.4.11? What if L8 does not apply cleanly to 1.4.10? etc.... |
From: Jonathan A. <jo...@sq...> - 2007-02-05 05:29:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On Sunday, February 04, 2007, Paul wrote: >>>> I was cleaning up my -users and -devel folders, and stumbled >>>> across an email that questioned a security patch. Not the patch >>>> itself, but the deployment of it. The user had assumed it'd >>>> upgrade his 1.4.8 to 1.4.9a. While this isn't going to happen for >>>> a security patch, it did make me start thinking. >>>> I was thinking of identifying each patch with a specific code >>>> that is unique across versions. I was thinking of a bitwise >>>> operation of some sort, along with a deployment script. >>>> Take for example, you're running 1.4.9a. The version of your >>>> SquirrelMail is 1.4.9a patch L0. We release a security update, >>>> which we tag as 1, so your patch level becomes L1. Later we >>>> release a second patch which is tagged as 2, so applying both >>>> patches takes you to L3. Later we release another patch, which is >>>> patch 4. Now if you've been a good SquirrelMail admin, your patch >>>> level is now L7. However, say you missed patch 2, your patch >>>> level is L5. More details on bitwise operations can be found on >>>> wikipedia [1] for those unfamiliar with them. >>> Sounds like a neat idea, but how would this affect people who are >>> running 1.4.9a (when the current version is, say, 1.4.12) and >>> instead of upgrading, they just take all the security patches that >>> are released and apply them....?? >> We can provide the "scripts" as a small package to download. The >> patch level can be kept outside of the SQM code, and stored in a >> .php file. > OK, but my question is more about what the meaning of patch levels is > when the main SM version is older. If L0 starts with SM 1.4.10, and > if we start at L0 again with SM 1.4.11, then managing patch levels for > SM 1.4.10 beyond the release of SM 1.4.11 is either very ambiguous or > quite a lot of maintenance, especially if we do it for every release > separately. You don't reset the patch level number. Maybe "level" was a bad term, I guess just a "patch number". The numeric just increases. It's also not sequential either, otherwise bitwise math wouldn't work right. For example: Patch 1: 00000001 Patch 2: 00000002 Patch 3: 00000004 Patch 4: 00000008 Patch 5: 00000010 Patch 6: 00000020 Patch 7: 00000030 If all the above patches were installed, you'd get a patch "level" of 0000003F. > So if we do the opposite and never reset back to L0, then if there > were five levels before 1.4.11 was released, does 1.4.10-L6 imply > that only security patches are applied in L6, or is there any other > fixes from 1.4.11 included in it from 1.4.11? Probably only security fixes should be supplied as patches like this. > What if L8 does not apply cleanly to 1.4.10? etc.... Then the patch "level" isn't increased in your files, and a report would be generated to tell you something wasn't right. This was originally a "random thought". I get them often, and can usually be dismissed by chuckling at me and pointing. I think this might be one of those ideas that can probably be sent to the black hole, unless there is a genuine interest. - -- Jonathan Angliss <jo...@sq...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFxsCHK4PoFPj9H3MRAmCIAKD7MspzGPDVUK3UpovajVlLW45uoACgvr2E P1poNsEZt+9XBOE7PMvGIVw= =QI+l -----END PGP SIGNATURE----- |
From: Paul L. <pa...@sq...> - 2007-02-05 06:21:26
|
On 2/4/07, Jonathan Angliss <jo...@sq...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Paul, > On Sunday, February 04, 2007, Paul wrote: > >>>> I was cleaning up my -users and -devel folders, and stumbled > >>>> across an email that questioned a security patch. Not the patch > >>>> itself, but the deployment of it. The user had assumed it'd > >>>> upgrade his 1.4.8 to 1.4.9a. While this isn't going to happen for > >>>> a security patch, it did make me start thinking. > > >>>> I was thinking of identifying each patch with a specific code > >>>> that is unique across versions. I was thinking of a bitwise > >>>> operation of some sort, along with a deployment script. > > >>>> Take for example, you're running 1.4.9a. The version of your > >>>> SquirrelMail is 1.4.9a patch L0. We release a security update, > >>>> which we tag as 1, so your patch level becomes L1. Later we > >>>> release a second patch which is tagged as 2, so applying both > >>>> patches takes you to L3. Later we release another patch, which is > >>>> patch 4. Now if you've been a good SquirrelMail admin, your patch > >>>> level is now L7. However, say you missed patch 2, your patch > >>>> level is L5. More details on bitwise operations can be found on > >>>> wikipedia [1] for those unfamiliar with them. > > >>> Sounds like a neat idea, but how would this affect people who are > >>> running 1.4.9a (when the current version is, say, 1.4.12) and > >>> instead of upgrading, they just take all the security patches that > >>> are released and apply them....?? > > >> We can provide the "scripts" as a small package to download. The > >> patch level can be kept outside of the SQM code, and stored in a > >> .php file. > > > OK, but my question is more about what the meaning of patch levels is > > when the main SM version is older. If L0 starts with SM 1.4.10, and > > if we start at L0 again with SM 1.4.11, then managing patch levels for > > SM 1.4.10 beyond the release of SM 1.4.11 is either very ambiguous or > > quite a lot of maintenance, especially if we do it for every release > > separately. > > You don't reset the patch level number. Maybe "level" was a bad term, > I guess just a "patch number". The numeric just increases. It's also > not sequential either, otherwise bitwise math wouldn't work right. For > example: > > Patch 1: 00000001 > Patch 2: 00000002 > Patch 3: 00000004 > Patch 4: 00000008 > Patch 5: 00000010 > Patch 6: 00000020 > Patch 7: 00000030 > > If all the above patches were installed, you'd get a patch "level" of > 0000003F. Right, sorry, I forgot about the binary number scheme, which is a nice idea, but I still don't see how this will map easily to SM release numbers, which is a different issue. > > So if we do the opposite and never reset back to L0, then if there > > were five levels before 1.4.11 was released, does 1.4.10-L6 imply > > that only security patches are applied in L6, or is there any other > > fixes from 1.4.11 included in it from 1.4.11? > > Probably only security fixes should be supplied as patches like this. Yeah, I'd agree. But what do we do with the patch number for version 1.4.11, which has the equivalent of L3F? Do we keep it at 3F right out of the box anyway? That would be a possible solution, but would be misleading because there will come a time when updating 1.4.10 to L8B2 is impossible due to the codebase differences between 1.4.10 and 1.4.33. :-) If we reset every version to L0, then I'm not even sure how we'd help people track the security state of every version before the current one... > > What if L8 does not apply cleanly to 1.4.10? etc.... > > Then the patch "level" isn't increased in your files, and a report > would be generated to tell you something wasn't right. > > This was originally a "random thought". I get them often, and can > usually be dismissed by chuckling at me and pointing. I think this > might be one of those ideas that can probably be sent to the black > hole, unless there is a genuine interest. I responded cuz I think at least the intention is a nice one, but I just can't see an easy way to rectify patch versions with SM release versions... |
From: Jonathan A. <jo...@sq...> - 2007-02-06 06:18:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On Monday, February 05, 2007, Paul wrote: > On 2/4/07, Jonathan Angliss <jo...@sq...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Paul, >> On Sunday, February 04, 2007, Paul wrote: >> >>>> I was cleaning up my -users and -devel folders, and stumbled >> >>>> across an email that questioned a security patch. Not the patch >> >>>> itself, but the deployment of it. The user had assumed it'd >> >>>> upgrade his 1.4.8 to 1.4.9a. While this isn't going to happen for >> >>>> a security patch, it did make me start thinking. >> >> >>>> I was thinking of identifying each patch with a specific code >> >>>> that is unique across versions. I was thinking of a bitwise >> >>>> operation of some sort, along with a deployment script. >> >> >>>> Take for example, you're running 1.4.9a. The version of your >> >>>> SquirrelMail is 1.4.9a patch L0. We release a security update, >> >>>> which we tag as 1, so your patch level becomes L1. Later we >> >>>> release a second patch which is tagged as 2, so applying both >> >>>> patches takes you to L3. Later we release another patch, which is >> >>>> patch 4. Now if you've been a good SquirrelMail admin, your patch >> >>>> level is now L7. However, say you missed patch 2, your patch >> >>>> level is L5. More details on bitwise operations can be found on >> >>>> wikipedia [1] for those unfamiliar with them. >> >> >>> Sounds like a neat idea, but how would this affect people who are >> >>> running 1.4.9a (when the current version is, say, 1.4.12) and >> >>> instead of upgrading, they just take all the security patches that >> >>> are released and apply them....?? >> >> >> We can provide the "scripts" as a small package to download. The >> >> patch level can be kept outside of the SQM code, and stored in a >> >> .php file. >> >> > OK, but my question is more about what the meaning of patch levels is >> > when the main SM version is older. If L0 starts with SM 1.4.10, and >> > if we start at L0 again with SM 1.4.11, then managing patch levels for >> > SM 1.4.10 beyond the release of SM 1.4.11 is either very ambiguous or >> > quite a lot of maintenance, especially if we do it for every release >> > separately. >> >> You don't reset the patch level number. Maybe "level" was a bad term, >> I guess just a "patch number". The numeric just increases. It's also >> not sequential either, otherwise bitwise math wouldn't work right. For >> example: >> >> Patch 1: 00000001 >> Patch 2: 00000002 >> Patch 3: 00000004 >> Patch 4: 00000008 >> Patch 5: 00000010 >> Patch 6: 00000020 >> Patch 7: 00000030 >> >> If all the above patches were installed, you'd get a patch "level" of >> 0000003F. > Right, sorry, I forgot about the binary number scheme, which is a nice > idea, but I still don't see how this will map easily to SM release > numbers, which is a different issue. I think this might be where the mix-up is coming in. It doesn't map to release numbers at all. It maps to security issues/patches. We track which patches need to be applied to which versions on the site as part of the security release. Maybe a table schema might help? +-------------+ | sec_release | +-------------+ | sec_id | | patch_id | | details | +-------------+ +-------------+ | sm_versions | +-------------+ | sm_ver_id | | major | | minor | | build | +-------------+ +-------------+ | sec_affect | +-------------+ | patch_id | | sm_ver_id | | patch_link | +-------------+ "patch_id" is based on the binary number above. When a security release is built a new patch id is created. We then select the affected versions from the sm_versions table, which builds a unique record in the sec_affect table, where patches for each version can be supplied. We can supply a check script which pings the security site, and sends the major,minor, build number, and current "patch level". The security site replies if you are "ok" or not. >> > So if we do the opposite and never reset back to L0, then if there >> > were five levels before 1.4.11 was released, does 1.4.10-L6 imply >> > that only security patches are applied in L6, or is there any other >> > fixes from 1.4.11 included in it from 1.4.11? >> >> Probably only security fixes should be supplied as patches like this. > Yeah, I'd agree. But what do we do with the patch number for version > 1.4.11, which has the equivalent of L3F? Do we keep it at 3F right > out of the box anyway? No, you wouldn't need to. New releases would include the patch, so the above "sec_affect" record wouldn't exist for the newly released sm_version record. This would essentially reset each version to L0, but the patch_ids still increase. It's the link in the sec_affect table (this is pseudo tables if you hadn't guessed) that determines if your release requires the update. > That would be a possible solution, but would be misleading because > there will come a time when updating 1.4.10 to L8B2 is impossible > due to the codebase differences between 1.4.10 and 1.4.33. :-) If we > reset every version to L0, then I'm not even sure how we'd help > people track the security state of every version before the current > one... Okay, with the example of the above versions, we release patch 6 on SM 1.4.10. A good sysadmin would have they patch "level" of 3F. We then release 1.4.11. The patch "level" on that new release is 0 as (in general practise), all previous patches have already been applied. Their would be no sec_affect record showing that 1.4.11 needed patches 1-6. Shortly after the release, we release patch 7. The SM 1.4.10 release is now at 7F, and 1.4.11 is now at 40 (see Eugene's response on my last to see where I borked the binary numbers). Next patch would put 1.4.10 at FF, while 1.4.11 would be at C0. Now, if at a later point in time, we discover that some changes between the release of 1.4.10, and 1.4.11 reverted the changes for patch 2, a new record can be added to sec_affect for the 1.4.11 version, and a new patch built. This would then mean that 1.4.11 should be at C2, while 1.4.10 should still be at FF. There are going to be times where a security issue doesn't affect one release, but affects others, for example between devel/stable. I think this is easily addressed by the fact that there will be no record in sec_affect to link an sm_version to a patch_id/sec_id. >>> What if L8 does not apply cleanly to 1.4.10? etc.... >> Then the patch "level" isn't increased in your files, and a report >> would be generated to tell you something wasn't right. >> This was originally a "random thought". I get them often, and can >> usually be dismissed by chuckling at me and pointing. I think this >> might be one of those ideas that can probably be sent to the black >> hole, unless there is a genuine interest. > I responded cuz I think at least the intention is a nice one, but I > just can't see an easy way to rectify patch versions with SM release > versions... I hope the pseudo table schema above makes it a little clearer, along with the slightly better example between 1.4.10, and 1.4.11. - -- Jonathan Angliss <jo...@sq...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFyB1rK4PoFPj9H3MRAsbOAKCaTo4e4Kxj9qDKGTipMeiRQpVycACeNGin Ne3r7JtIWqcAsg7/Zz7CAIo= =EKAk -----END PGP SIGNATURE----- |
From: Paul L. <pa...@sq...> - 2007-02-06 23:51:36
|
On 2/5/07, Jonathan Angliss <jo...@sq...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Paul, > On Monday, February 05, 2007, Paul wrote: > > On 2/4/07, Jonathan Angliss <jo...@sq...> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi Paul, > >> On Sunday, February 04, 2007, Paul wrote: > >> >>>> I was cleaning up my -users and -devel folders, and stumbled > >> >>>> across an email that questioned a security patch. Not the patch > >> >>>> itself, but the deployment of it. The user had assumed it'd > >> >>>> upgrade his 1.4.8 to 1.4.9a. While this isn't going to happen for > >> >>>> a security patch, it did make me start thinking. > >> > >> >>>> I was thinking of identifying each patch with a specific code > >> >>>> that is unique across versions. I was thinking of a bitwise > >> >>>> operation of some sort, along with a deployment script. > >> > >> >>>> Take for example, you're running 1.4.9a. The version of your > >> >>>> SquirrelMail is 1.4.9a patch L0. We release a security update, > >> >>>> which we tag as 1, so your patch level becomes L1. Later we > >> >>>> release a second patch which is tagged as 2, so applying both > >> >>>> patches takes you to L3. Later we release another patch, which is > >> >>>> patch 4. Now if you've been a good SquirrelMail admin, your patch > >> >>>> level is now L7. However, say you missed patch 2, your patch > >> >>>> level is L5. More details on bitwise operations can be found on > >> >>>> wikipedia [1] for those unfamiliar with them. > >> > >> >>> Sounds like a neat idea, but how would this affect people who are > >> >>> running 1.4.9a (when the current version is, say, 1.4.12) and > >> >>> instead of upgrading, they just take all the security patches that > >> >>> are released and apply them....?? > >> > >> >> We can provide the "scripts" as a small package to download. The > >> >> patch level can be kept outside of the SQM code, and stored in a > >> >> .php file. > >> > >> > OK, but my question is more about what the meaning of patch levels is > >> > when the main SM version is older. If L0 starts with SM 1.4.10, and > >> > if we start at L0 again with SM 1.4.11, then managing patch levels for > >> > SM 1.4.10 beyond the release of SM 1.4.11 is either very ambiguous or > >> > quite a lot of maintenance, especially if we do it for every release > >> > separately. > >> > >> You don't reset the patch level number. Maybe "level" was a bad term, > >> I guess just a "patch number". The numeric just increases. It's also > >> not sequential either, otherwise bitwise math wouldn't work right. For > >> example: > >> > >> Patch 1: 00000001 > >> Patch 2: 00000002 > >> Patch 3: 00000004 > >> Patch 4: 00000008 > >> Patch 5: 00000010 > >> Patch 6: 00000020 > >> Patch 7: 00000030 > >> > >> If all the above patches were installed, you'd get a patch "level" of > >> 0000003F. > > > Right, sorry, I forgot about the binary number scheme, which is a nice > > idea, but I still don't see how this will map easily to SM release > > numbers, which is a different issue. > > I think this might be where the mix-up is coming in. It doesn't map > to release numbers at all. It maps to security issues/patches. We > track which patches need to be applied to which versions on the site > as part of the security release. Maybe a table schema might help? > > +-------------+ > | sec_release | > +-------------+ > | sec_id | > | patch_id | > | details | > +-------------+ > > +-------------+ > | sm_versions | > +-------------+ > | sm_ver_id | > | major | > | minor | > | build | > +-------------+ > > +-------------+ > | sec_affect | > +-------------+ > | patch_id | > | sm_ver_id | > | patch_link | > +-------------+ > > > "patch_id" is based on the binary number above. When a security > release is built a new patch id is created. We then select the > affected versions from the sm_versions table, which builds a unique > record in the sec_affect table, where patches for each version can be > supplied. This is exactly what I meant by "a lot of maintenance". I agree this kind of system is technically probably feasible, but it will require possibly a LOT of work if we are going to publish patches for ALL releases of SM 1.4.x (and 1.5.x and 2.0.x too?) for each and every security patch. When do we stop supplying patches for old releases? What about scenarios where an older version has such outdated code that really fixing a certain security hole involves as much work making a patch as it does just upgrading? > We can supply a check script which pings the security site, > and sends the major,minor, build number, and current "patch level". > The security site replies if you are "ok" or not. > > >> > So if we do the opposite and never reset back to L0, then if there > >> > were five levels before 1.4.11 was released, does 1.4.10-L6 imply > >> > that only security patches are applied in L6, or is there any other > >> > fixes from 1.4.11 included in it from 1.4.11? > >> > >> Probably only security fixes should be supplied as patches like this. > > > Yeah, I'd agree. But what do we do with the patch number for version > > 1.4.11, which has the equivalent of L3F? Do we keep it at 3F right > > out of the box anyway? > > No, you wouldn't need to. New releases would include the patch, so > the above "sec_affect" record wouldn't exist for the newly released > sm_version record. This would essentially reset each version to L0, > but the patch_ids still increase. It's the link in the sec_affect > table (this is pseudo tables if you hadn't guessed) that determines if > your release requires the update. Fine, I think the actual answer to my question is the fact that you propose that a separate patch be offered for every SM release for any ONE security patch. I've no problem with this, just want to point out how much work it will be to maintain. > > That would be a possible solution, but would be misleading because > > there will come a time when updating 1.4.10 to L8B2 is impossible > > due to the codebase differences between 1.4.10 and 1.4.33. :-) If we > > reset every version to L0, then I'm not even sure how we'd help > > people track the security state of every version before the current > > one... > > Okay, with the example of the above versions, we release patch 6 on SM > 1.4.10. A good sysadmin would have they patch "level" of 3F. We then > release 1.4.11. The patch "level" on that new release is 0 as (in > general practise), all previous patches have already been applied. > Their would be no sec_affect record showing that 1.4.11 needed patches > 1-6. Shortly after the release, we release patch 7. The SM 1.4.10 > release is now at 7F, and 1.4.11 is now at 40 (see Eugene's response > on my last to see where I borked the binary numbers). Next patch > would put 1.4.10 at FF, while 1.4.11 would be at C0. > > Now, if at a later point in time, we discover that some changes > between the release of 1.4.10, and 1.4.11 reverted the changes for > patch 2, a new record can be added to sec_affect for the 1.4.11 > version, and a new patch built. This would then mean that 1.4.11 > should be at C2, while 1.4.10 should still be at FF. > > There are going to be times where a security issue doesn't affect one > release, but affects others, for example between devel/stable. I > think this is easily addressed by the fact that there will be no > record in sec_affect to link an sm_version to a patch_id/sec_id. > > >>> What if L8 does not apply cleanly to 1.4.10? etc.... > > >> Then the patch "level" isn't increased in your files, and a report > >> would be generated to tell you something wasn't right. > > >> This was originally a "random thought". I get them often, and can > >> usually be dismissed by chuckling at me and pointing. I think this > >> might be one of those ideas that can probably be sent to the black > >> hole, unless there is a genuine interest. > > > I responded cuz I think at least the intention is a nice one, but I > > just can't see an easy way to rectify patch versions with SM release > > versions... > > I hope the pseudo table schema above makes it a little clearer, along > with the slightly better example between 1.4.10, and 1.4.11. |
From: Jonathan A. <jo...@sq...> - 2007-02-07 03:05:26
|
On Tue, February 6, 2007 17:51, Paul Lesniewski wrote: >> "patch_id" is based on the binary number above. When a security >> release is built a new patch id is created. We then select the affect= ed >> versions from the sm_versions table, which builds a unique record in t= he >> sec_affect table, where patches for each version can be supplied. > > This is exactly what I meant by "a lot of maintenance". I agree this > kind of system is technically probably feasible, but it will require > possibly a LOT of work if we are going to publish patches for ALL relea= ses > of SM 1.4.x (and 1.5.x and 2.0.x too?) for each and every security patc= h. But you wouldn't have to build a patch for /every/ version because, for the most part, patches for 1.4.9 also apply to 1.4.8, you'd just point th= e link to the same place, as we do now. > When do we stop supplying patches for old releases? This comes into the technical side of when we stop supporting a version.=20 As we've never really officially announced a time frame for support, I think that'd need to be addressed first. > What about scenarios where an older version has such outdated code > that really fixing a certain security hole involves as much work making= a > patch as it does just upgrading? If the version is that old the code requires such a massive amount of change, we'd probably have already gone past the "end of life" for that version, and it wouldn't be supported any more. >>> Yeah, I'd agree. But what do we do with the patch number for version >>> 1.4.11, which has the equivalent of L3F? Do we keep it at 3F right >>> out of the box anyway? >> No, you wouldn't need to. New releases would include the patch, so >> the above "sec_affect" record wouldn't exist for the newly released >> sm_version record. This would essentially reset each version to L0, b= ut >> the patch_ids still increase. It's the link in the sec_affect table >> (this is pseudo tables if you hadn't guessed) that determines if >> your release requires the update. > Fine, I think the actual answer to my question is the fact that you > propose that a separate patch be offered for every SM release for any O= NE > security patch. I've no problem with this, just want to point out how > much work it will be to maintain. I don't think a separate patch would be needed at all. The patch link ca= n point to the same place for any number of releases. This is exactly what we do now, and don't see any reason to change that. The idea was merely = a method to make it easier for administrators to check/track which updates they have already included/require. --=20 Jonathan Angliss <jo...@sq...> |
From: Paul L. <pa...@sq...> - 2007-02-08 03:00:41
|
On 2/6/07, Jonathan Angliss <jo...@sq...> wrote: > > On Tue, February 6, 2007 17:51, Paul Lesniewski wrote: > > >> "patch_id" is based on the binary number above. When a security > >> release is built a new patch id is created. We then select the affected > >> versions from the sm_versions table, which builds a unique record in the > >> sec_affect table, where patches for each version can be supplied. > > > > This is exactly what I meant by "a lot of maintenance". I agree this > > kind of system is technically probably feasible, but it will require > > possibly a LOT of work if we are going to publish patches for ALL releases > > of SM 1.4.x (and 1.5.x and 2.0.x too?) for each and every security patch. > > But you wouldn't have to build a patch for /every/ version because, for > the most part, patches for 1.4.9 also apply to 1.4.8, you'd just point the > link to the same place, as we do now. Yes, but with this system you have to be prepared for the possibility that it won't be that simple. Even minor changes to code in the vicinity of a security patch will necessitate separate patches for all versions that differ. How much fuzz in a patch is acceptable before you create a new one? I'd say none is desired. And it could get worse: if we are still supporting 1.4 when 2.0 is launched, maintaining patches between the two branches and all versions therein could be pretty ugly. Even if it's as simple as your example, it's still no small amount of work to just verify that the patch works on all affected versions and update the security/patch database, etc. > > When do we stop supplying patches for old releases? > > This comes into the technical side of when we stop supporting a version. > As we've never really officially announced a time frame for support, I > think that'd need to be addressed first. Agreed. > > What about scenarios where an older version has such outdated code > > that really fixing a certain security hole involves as much work making a > > patch as it does just upgrading? > > If the version is that old the code requires such a massive amount of > change, we'd probably have already gone past the "end of life" for that > version, and it wouldn't be supported any more. I don't agree. Sometimes something gets added/changed, even in STABLE that restructures a limited piece of code, but if a security issue is found in that same code, we could possibly run into hassles creating a clean, sensical patch for the versions before (or after?) those changes were made. > >>> Yeah, I'd agree. But what do we do with the patch number for version > >>> 1.4.11, which has the equivalent of L3F? Do we keep it at 3F right > >>> out of the box anyway? > > >> No, you wouldn't need to. New releases would include the patch, so > >> the above "sec_affect" record wouldn't exist for the newly released > >> sm_version record. This would essentially reset each version to L0, but > >> the patch_ids still increase. It's the link in the sec_affect table > >> (this is pseudo tables if you hadn't guessed) that determines if > >> your release requires the update. > > > Fine, I think the actual answer to my question is the fact that you > > propose that a separate patch be offered for every SM release for any ONE > > security patch. I've no problem with this, just want to point out how > > much work it will be to maintain. > > I don't think a separate patch would be needed at all. The patch link can > point to the same place for any number of releases. This is exactly what > we do now, and don't see any reason to change that. The idea was merely a > method to make it easier for administrators to check/track which updates > they have already included/require. |
From: Chris H. <ta...@sq...> - 2007-02-08 07:06:57
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Lesniewski wrote: >>> When do we stop supplying patches for old releases? >> This comes into the technical side of when we stop supporting a version. >> As we've never really officially announced a time frame for support, I >> think that'd need to be addressed first. Current stable is supported. When a new stable version is released, all older versions are obsoleted and unsupported. Why complicate life? Chris ta...@sq... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFFyswL98ixrK2vMtARArlHAJ45rYTCVZYeFjyashZ9LVYrBE/wigCeK2KU kp8J7/QKdFoVzGtt58qUaig= =WWLj -----END PGP SIGNATURE----- |
From: Cor B. <co...@xs...> - 2007-02-08 11:34:58
|
> >> This comes into the technical side of when we stop supporting a version. > >> As we've never really officially announced a time frame for support, I > >> think that'd need to be addressed first. > > Current stable is supported. When a new stable version is released, all > older versions are obsoleted and unsupported. Why complicate life? Because life is complicated. You cant expect everyone to upgrade on a moments notice when a new stable version comes out. I think that not supporting at least a few previous versions would actually be bad for security. People will just not apply the security updates (since there is nothing to apply) I think it would be nice if SM supported at least 2 minor versions before the current stable. So if current is 1.4.9, it would be 1.4.8 and 1.4.7. If the current stable is 2.0, you would also support 1.4.9 and 1.4.8 for instance. Cor |
From: Erin S. <ebu...@gm...> - 2007-03-01 16:58:48
|
On 2/8/07, Cor Bosman <co...@xs...> wrote: > > Am I missing something obvious here? Stable is for fixes only, no new > > features or development. Therefore, applying the patches would simply > > bring you up to the current stable's level - why not just install the > > current stable and be done with it? > > We have over 100.000 regular customers. Tens of thousands simultaneous, > with about 25 servers dedicated to squirrelmail/imap server. I am not going > to 'just install stable and be done with it'. if anything, it takes many > days to fully integrate a new version on our systems, applying local patches, > verifying local plugins, testing if everything still works and a new version > didnt break anything. A few minutes of problems could spell disaster. If you want SM to be a valuable asset to large installations, you have to acknowledge the business-critical nature of email, and (as Cor said) the importance of making sure things continue to work. As most of us devs do not run large installs, it's easy to dismiss the upgrades as trivial... Here are some examples of "enterprise" support plans that I dug up w/ google: Symantec Enterprise support: http://www.symantec.com/region/reg_eu/techsupp/enterprise/static/support_policy.html The table at the bottom is the relevant bit: current is fully supported - like our current stable branch; prior is the one before that, and they do limited testing of that for 30 months after it moves from current to prior; inactive releases (post-30 months) recieve only best-effort attention, no planned service or testing. Adobe Enterprise support: http://www.adobe.com/support/programs/policies/policy_enterprise_lifecycle.html Arbitrary 5 years of support from the .0 release. Longer terms than that are (as might be expected) subject to negotiation. ;) Those are two examples. Of course, we don't get paid for providing extended patches and fixes for previous releases - but I don't think we can just drop support. *IF* we want to phase out support of releases, the usual thing to do is mark them deprecated (I know, that's a Java thing - but it's also good practice), and provide a sufficient grace-period for migration before support terminates. So, if we wanted to create a policy, we could say, "Anything before release 1.4.9 is now deprecated. Support for these releases, including security fixes, will no longer be provided after [insert arbitrary date at least one year from now]." What do you think about that, Cor? Erin -- 'Waste of a good apple' -Samwise Gamgee |
From: Cor B. <co...@xs...> - 2007-03-01 17:30:15
|
> What do you think about that, Cor? I like the 30 month policy ;) Im not quite sure why you are saying 'anything prior to 1.4.9'. Personally I see 1.4.9a as 'Current', and 1.4.8 as 'prior'. I dont think its a good idea to make a version unsupported just because you release two version 2 days apart. And even the policy of calling the previous version 'prior' and giving it some form of support, and the versions before that are end-of-support, is not always going to work, especially when for whatever reason SM releases a few versions in rapid succession. I think reality is that a lot of companies, but perhaps also individuals, do not immediately upgrade when a new version comes out. If it works, dont fix it and all that. Forward 6 months, and company is still on the previous version but now a serious security problem arises. For companies it's often quite difficult to upgrade to a new version immediately because thats the only one having a fix. There are scheduled downtimes, maintenance windows, test periods, etc etc. So you're going to end up with people running vulnerable versions, even though they are aware of the issue. But where do you balance this. I realise you cant support every previous version. So there has to be some middle ground on this. Someone previously mentioned a 6 month period. I personally find that a little short, I would prefer 1 year, but I would prefer any time based policy over a version based policy. Honestly, for our company this issue isnt a problem. I can usually backport security patches, if we werent involved in the issue in the first place :) (darn dutch hackers! :) But I can relate to other companies that are in a similar position. Cor |
From: Fredrik J. <jer...@sq...> - 2007-03-01 18:33:01
|
>> What do you think about that, Cor? >> > > I like the 30 month policy ;) > > > Im not quite sure why you are saying 'anything prior to 1.4.9'. > Personally I see 1.4.9a as 'Current', and 1.4.8 as 'prior'. I dont think > its a good idea to make a version unsupported just because you release two > version 2 days apart. > > And even the policy of calling the previous version 'prior' and giving > it some form of support, and the versions before that are end-of-support, > is not always going to work, especially when for whatever reason SM > releases a few versions in rapid succession. > > I think reality is that a lot of companies, but perhaps also individuals, > do not immediately upgrade when a new version comes out. If it works, > dont fix it and all that. Forward 6 months, and company is still on the > previous version but now a serious security problem arises. For companies > it's often quite difficult to upgrade to a new version immediately > because thats the only one having a fix. There are scheduled downtimes, > maintenance windows, test periods, etc etc. So you're going to end up with > people running vulnerable versions, even though they are aware of the > issue. > > But where do you balance this. I realise you cant support every previous > version. So there has to be some middle ground on this. Someone previously > mentioned a 6 month period. I personally find that a little short, I > would prefer 1 year, but I would prefer any time based policy over a > version based policy. Might have been me: <http://marc.theaimsgroup.com/?t=117123988300001&r=1&w=2>. > Honestly, for our company this issue isnt a problem. I can usually > backport security patches, if we werent involved in the issue in the first > place :) (darn dutch hackers! :) But I can relate to other companies that > are in a similar position. Sincerely, Fredrik |
From: Eugene <ge...@ge...> - 2007-02-05 17:16:35
|
Hi people, From: "Jonathan Angliss" <jo...@sq...> > You don't reset the patch level number. Maybe "level" was a bad term, > I guess just a "patch number". The numeric just increases. It's also > not sequential either, otherwise bitwise math wouldn't work right. For > example: > > Patch 1: 00000001 > Patch 2: 00000002 > Patch 3: 00000004 > Patch 4: 00000008 > Patch 5: 00000010 > Patch 6: 00000020 > Patch 7: 00000030 > > If all the above patches were installed, you'd get a patch "level" of > 0000003F. That's probably "Patch 7: 00000040" and 0000007F =)) Bur what whould happen when we run out of 32 bits? Eugene |
From: Jonathan A. <jo...@sq...> - 2007-02-06 05:52:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Eugene, On Monday, February 05, 2007, Eugene wrote: >> You don't reset the patch level number. Maybe "level" was a bad term, >> I guess just a "patch number". The numeric just increases. It's also >> not sequential either, otherwise bitwise math wouldn't work right. For >> example: >> >> Patch 1: 00000001 >> Patch 2: 00000002 >> Patch 3: 00000004 >> Patch 4: 00000008 >> Patch 5: 00000010 >> Patch 6: 00000020 >> Patch 7: 00000030 >> >> If all the above patches were installed, you'd get a patch "level" of >> 0000003F. > That's probably "Patch 7: 00000040" and 0000007F =)) Well spotted ;) > Bur what whould happen when we run out of 32 bits? I'll address that question when we hit out 2 millionth security patch. - -- Jonathan Angliss <jo...@sq...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFyBeBK4PoFPj9H3MRAnxzAKDaERQ+hQ2Y3D3LU6fvcjIOSctwsQCg8hhH LyUOnSDsr68nW9OfTHWhrMw= =NmHs -----END PGP SIGNATURE----- |
From: Eugene <ge...@ge...> - 2007-02-06 21:38:55
|
Hi people, From: "Jonathan Angliss" <jo...@sq...> >> Bur what whould happen when we run out of 32 bits? > I'll address that question when we hit out 2 millionth security patch. That would be sooner than expected -)) The scheme is logarithmic, in a sense -- in other words, each patch maps to one bit, so the maximum number of patches is 32 (apart from BigInt and things like that). Come to think of it, what about simple sets (without bit mapping) encoded, say, as L1+2+5+6 or L1_2_5_6 for installation with patches 1,2,5,6 applied? Best regards Eugene |
From: Chris H. <ta...@sq...> - 2007-02-08 12:51:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cor Bosman wrote: > I think it would be nice if SM supported at least 2 minor versions before > the current stable. So if current is 1.4.9, it would be 1.4.8 and 1.4.7. > If the current stable is 2.0, you would also support 1.4.9 and 1.4.8 for > instance. Am I missing something obvious here? Stable is for fixes only, no new features or development. Therefore, applying the patches would simply bring you up to the current stable's level - why not just install the current stable and be done with it? Remember, life is only complicated if we *choose to make it so*. Complicated means more effort and maintenance, which, historically, ain't a good thing for us. Simple is good. Simple works. Simple actually gets done. My $0.02 (rapidly depreciating) USD. Chris ta...@sq... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFFyxys98ixrK2vMtARAlK4AJ9euXXpCc0jStpqkzYb+hpkm/02uQCbBiye GOwOIg3f3AwMcDkhLdHuS8A= =Z9ao -----END PGP SIGNATURE----- |
From: Cor B. <co...@xs...> - 2007-02-08 13:27:28
|
> Am I missing something obvious here? Stable is for fixes only, no new > features or development. Therefore, applying the patches would simply > bring you up to the current stable's level - why not just install the > current stable and be done with it? We have over 100.000 regular customers. Tens of thousands simultaneous, with about 25 servers dedicated to squirrelmail/imap server. I am not going to 'just install stable and be done with it'. if anything, it takes many days to fully integrate a new version on our systems, applying local patches, verifying local plugins, testing if everything still works and a new version didnt break anything. A few minutes of problems could spell disaster. Oh but there's only small minor fixes. Yeah, ive heard that before..many times :) Im sure we're not the only one that will not just rush and install a new stable the microsecond it comes out. I would really prefer it if there were patches for 2 previous minor releases (id personally even settle for 1, but I bet lots of people will need 2) so I dont have to 'rush a new stable and be done with it when there is a serious security issue threatening the privacy and/or security of our customers and ourselves'. Id prefer to install a new stable at my own pace. (and I regularly do) > Remember, life is only complicated if we *choose to make it so*. No. Life is complicated. No such thing as simple when you're supporting a large system interacting with other large systems. Regards, Cor |
From: Chris H. <ta...@sq...> - 2007-03-02 04:39:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erin Schnabel wrote: > Those are two examples. Of course, we don't get paid for providing > extended patches and fixes for previous releases - but I don't think > we can just drop support. If you want to volunteer to back-port security patches into old releases, nobody's going to stop you. > *IF* we want to phase out support of releases, the usual thing to do > is mark them deprecated (I know, that's a Java thing - but it's also > good practice), and provide a sufficient grace-period for migration > before support terminates. > > So, if we wanted to create a policy, we could say, "Anything before > release 1.4.9 is now deprecated. Support for these releases, including > security fixes, will no longer be provided after [insert arbitrary > date at least one year from now]." If you want this, you should consider using a packaged version of Squirrelmail, such as the one Debian provides. It's difficult enough to get developers to nail down security patches in two source trees (stable AND devel), let alone stable, devel, and obsolete versions as well. Chris Hilts ta...@sq... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFF56pv98ixrK2vMtARAr5MAJkBCUdpC0Nk3MIOU0gSA/R2W9f60QCaAzE2 AB+c5UlABxlk007XhDrc+aw= =2vWC -----END PGP SIGNATURE----- |
From: Thijs K. <ki...@sq...> - 2007-03-03 21:30:40
|
On Thu, 2007-03-01 at 23:39 -0500, Chris Hilts wrote: > If you want to volunteer to back-port security patches into old > releases, nobody's going to stop you. The question of time is the most important one here. But I think we're doing pretty OK by providing the diffs for the security issues we release. I believe that those diffs generally apply to stable at least a year back, if not often to the start of the 1.4.x series. For me that seems like an acceptable balance. Generating and providing loose patches is not too much work for us, and I think it works for users not willing to upgrade yet aswell. We also answer questions about it if they pop up. If this is not sufficient security support, I'd like to hear what exactly could improve our support. What is the value of releasing 1.4.8a with the same security patch? Then users can just apply the patch themselves. > If you want this, you should consider using a packaged version of > Squirrelmail, such as the one Debian provides. It's difficult enough to > get developers to nail down security patches in two source trees (stable > AND devel), let alone stable, devel, and obsolete versions as well. Guess who is backporting the patches to those Debian packages ;) Thijs |