Re: [fossil-users] [sqlite] Mailing list shutting down...
On Thu, 2018-06-14 at 20:36 +0100, Thomas wrote: > On 2018-06-14 17:47, Roy Keene wrote: > > If it's any conideration, if it's not a mailing list or something > > else > > pushed to me, I'll never see it. A fossil users' forum will never > > get > > checked (pulled) by me since I am just too lazy to remember to do > > so on > > any regular frequency. There may be others like me who are busy > > but can > > occasionally check email. Agreed 100%. This is the lowest noise option. > > Mailing lists in general are disappearing and forums are coming in > more > and more. Yes, the world is going to hell in our lifetime. Dare I suggest we bin all the mailing list ideas and go back to Usenet? > There surely are loads of reasons but I'd like to only point > out that once the amount of posts increases no one wants to see all > those in their inbox. It's a huge pain in the ass to have to sign up for anything just to ask a question or report a bug. Huge. But as offensive and unmanageable as that is, having to have browser tabs open for dozens of web forums, having to come up with and manage passwords for each of those, and have to actively monitor each one to see if anything of interest happens to appear, is much worse. A decent email client can run on a terminal, over ssh or telnet, etc. and can handle all sorts of filtering and searching. Most mailing lists assign you a password and you don't even have to keep track of it; many email you password reminders on a regular basis and you don't even need it until you want to unsubscribe. Web forums are right out. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote: On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote: git branch -D name Eh, filesystems let you delete files. Unlike most filesystems, git lets you restore your deleted branches (yes, provided you don't gc the repo). Then just use a file system and various command line tools! But seriously, it's a philosophical difference between those who want to be able to rewrite their history to what they should have done and those who want to keep the history around to see what they did. I can understand for personal projects people might want stuff to disappear. And I can understand vandals want to make stuff disappear when they attack a system. But in a serious, large project there are often requirements for an audit trail. There is no downside to this given the cheapness of backing storage. And it can prevent all sorts of problems. In the places I work the problem tracking system entries are immutable. And while a lot of those places don't use source control for various reasons when they do use them the source changes and history of who did what and when he did it are also immutable. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Mon, Sep 01, 2014 at 05:29:41PM +0200, Stephan Beal wrote: Okay, more git bashing... Yeah. It's too easy _not_ to do. Git is just another steaming Linux-centric pile that makes me so thankful there are people like Dr. Hipp and you and all the fossil guys. Consider the following points: 1) The world is not Linux 2) See (1) above. There are many operating systems that aren't Linux 3) We want something safe that uses a proven database because source control is about controlling source, not losing it and not littering it all over your system. 4) We want something that builds without drama on many platforms using standards compliant compilers and without requiring gcc extensions or specific shells like bash or any other proprietary (yes, I said it!) gnu crap.. Git = MAJOR FAIL. 5) We want something efficient, compact and clean that doesn't depend on scripting languages or need add-ons to be useful. It shouldn't create dozens of executables and libraries all over the target system. Because if it sucks we're going to wanna yank it out cleanly. 6) We don't want to drag a thousand tons of gnu prereqs just to build an application or its documentation(!) and we don't want to depend on dozens of prereqs to run it. Heavy = bad, light = good. 7) A source control system should be sensible from the point of view of the person using it to manage source code. It should not be Linux-centric. It should not require you to understand its internals to use it effectively and it must not require you to understand the internals to avoid pitfalls and gotchas. Tricks = bad, least surprise = good. 8) Source control is not a hobby for normal healthy people. It's not something to become an expert in for chest-banging purposes. It's a critical tool that's supposed to stay the hell out of the way and let you write and keep track of code. You guys scored a huge win by creating fossil and basing it on sqlite. It's ingenious, it's simple, it's trustworthy, it's complete, and most of all it's nothing we _don't_ want in a source control system! Thank you! /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Tue, Sep 02, 2014 at 02:02:39PM -0400, Ron W wrote: On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote: Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? I think that the only way this will happen would be to fork Fossil into a new project. This would be because of the overall underlying goals of the Fossil project vs a Fossil-saurus project. As I understand it, Fossil is intentionally designed around the feature set provided by SQLite. Therefore, to support DB back-ends other than SQLite would not just require rewriting SQL queries, but significant re-working of Fossil's C implementation. I'm probably out of my area but it would seem writing a wrapper to transform the database calls to $BACKEND_OF_CHOICE would be in order unless sqlite does stuff that is really not appropriate for other databases and cannot readily be transformed to make sense with other databases. Theoretically it should be possible to do that without changing the API calls at all. You would just link the wrapper instead of sqlite. If you can get this to work it's obviously the safest, most low-impact way to do a major change like that while not breaking what already works. I have done stuff like this on another platform but am not familiar with any of the parts here i.e. I have no knowledge of C, fossil, etc. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.27
On Wed, Sep 11, 2013 at 08:49:14AM -0600, Warren Young wrote: On 9/11/2013 08:36, Michai Ramakers wrote: For my information: is WinXP still an 'officially supported' platform? I realise it's a bit old, but I happen to use fossil on that platform, occasionally. There are plenty of people still using XP for various reasons and tasks. Only 7 months left of MS support: http://goo.gl/dtpQj4 After that, no more security patches. So what? Maybe XP is safer than any of the NSA-approved Windows versions. My unpatched firewalled copy has been running for over 10 years without any issues. It's time to be migrating off XP. If you have to use Windows you may as well use XP. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.27
On Wed, Sep 11, 2013 at 09:08:05AM -0600, Warren Young wrote: On 9/11/2013 08:59, John Long wrote: On Wed, Sep 11, 2013 at 08:49:14AM -0600, Warren Young wrote: Only 7 months left of MS support: http://goo.gl/dtpQj4 So what? After the EOL date, XP will quickly start bit rotting. Given my copy is about 13 years old and still perfectly usable and has been running as-installed with exactly two KBs applied I really don't know what difference it makes if it's EOLd or not. Auto-update is the first thing that gets turned off on any Winstall I've ever done. There's a long list after that. Another fun problem with Win2K now is that if you're in a part of the world where DST rules changed in the past few years (e.g. USA) the time will be off during part of the year, since the time zone DB isn't being updated any more. But we're not talking about Win2K which had a much shorter shelf life and was obsolete a lot faster than XP was. Everything I need XP for (VPN and some apps for work), and everything a few million other people need it for already works. Software can't go unmaintained indefinitely without consequences. Each piece of software has an independent and unknown lifetime and in this case for many if not most users the consequences of going without maintenance are preferable to throwing money down the toilet on a crappier, more bloated version. Most people are either going to get something newer against their will if they buy a new PC or will stay with what they have until their hardware catches on fire. Bottom line is a lot of people are using XP and will not upgrade and it is really not appropriate for anybody to lecture them about doing it. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
Sorry for the delay. I've been swamped with work. On Wed, Aug 21, 2013 at 02:30:10PM +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 1:58 PM, John Long codeb...@inbox.lv wrote: Digital signing means I certify that I wrote this. This thing itself, and not something derived from it. Being one of those who doesn't place all that much worth on digital security (that's going to bite me one day), i would almost suggest that the different is splitting hairs in this case because the SHA1s of the files we are indirectly signing are just as valid as any PGP signature we might wrap around them. We then sign the SHA1s, in effect, as opposed to the content. Obviously, SHA1 can be attacked, but i have yet to see it happen. Couple things to mention here. One, SHA1 has been broken since 2005. It's not longer recommended for deployment in new cryptosystems. Since 2010 a practical attack was demonstrated. If you give fossil a PGP key and a keyphrase to enable signing then I don't disagree with your observation that the difference between SHA1 and PGP signing could be viewed as hair splitting. But that is because giving fossil a PGP key and keyphrase is an abuse of what it means to digitally sign something as we talked about earlier. A hash is a way to assign a token to some data. In theory, if the data is altered the hash will change. This guarantees (again in theory) integrity of the data. It doesn't have anything to do with *who is asserting* the data is valid. There are two value added things digital signing provides over hashing in this specific example when fossil uses SHA1. One, a person is taking responsibility for a commit and saying I did this. Two, PGP can use much stronger hashes than SHA1. What problem are we trying to solve? If we're worried about detecting inadvertant data corruption, then SHA1 is very likely good enough. If we're worried about malicious data corruption then SHA1 is not good enough on paper. If we want to know with virtual certainty who did this? then a PGP signature helps. If fossil signs everything with one key, then yes, it doesn't add much value beyond a hash because we know fossil did the actual update even though a person supplied the data to be committed. That is only really enforeable for network access. Once someone has local access they have full access to the repo. Local access to a fossil repo always uses ignores any credentials checks because it assumes that 1 copy of a repo belongs to 1 user (which is the normal/expected workflow). This is another value added item for PGP signing over a hash since the data could be completely replaced and rehashed (in theory, I don't know fossil) and the corruption couldn't be detected. This would be detected with digital signing because the attacker can't re-sign bad data. BTW, if I understood correctly and fossil does sign with somebody else's key, then this is a significant weakness in this attack (local access to repo) also since the attacker gains access to the private key which was in the repo. * Fossil notes and records for each commit component that the signature was verified successfully. Fossil does this once, upon commit once is kind of a misnomer here (and i just accidentally discovered a flaw in the check sig and forget approach): a manifest (checkin record) is read/processed at three different points: a) when the checkin happens. b) when the manifest arrives via a sync c) when doing a rebuild - that effectively feeds all of the existing manifests back through the db to rebuild metadata. If the rebuild can change previously signed contents then yes, it's seem problematical. In that case a signature isn't meaningful any more. Then I wrote: When I check in a project one of the things I check in is my PGP public key and a detached signature of my PGP public key. Then I detach-sign all my updates and check in updates and their detached signatures. Now I can verify any time in the future that any file in the repo was signed by me. I don't even need fossil to give me a place to store my pubkey because I simply check it in. This won't protect me against someone hacking my repo if he obtains my userid and password but I will be able to know if that happened. Sounds like way overkill to me, but i've been told that i am (by far) not as paranoid as i should be ;). But unless I missed something then it's a very simple way for people who want digitally-signed commits to use fossil, without any changes at all, to get the full benefit of signed commits, all using fossil's current capabilities to manage data of all kinds, not just program source. The only thing I might add is a cross-signature on the pubkey I check in. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
Stephan, Andy, Put briefly: when you tell fossil to give you the contents of file abcdef, it may internally go through several versions of that file on its way to generating the one you requested, applying deltas as it goes. The end result is that the content is logically immutable, and always convertible to its original form (as determined by SHA1 comparison), but Fossil doesn't actually store it immutably. Thanks for the information. It would seem there are two general issues. One is fossil needs a way to detect corruption of various data and metadata and that problem is solved by using SHA1. The other issue, which is specific to specific situations, is whether the hash alone is sufficient to protect against malicious alteration of the repository. In the first case it would seem SHA1 is still acceptable although it's increasingly becoming apparent SHA1's days as an ideal hash have come and gone. In the second case I think it's possible to prevent and/or detect of attacks on the repo with very minimal workflow adjustments I outlined earlier, or something similar to that, without any changes to fossil at all. Thanks guys. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
On Wed, Aug 28, 2013 at 06:40:19PM +0200, Stephan Beal wrote: On Wed, Aug 28, 2013 at 6:26 PM, John Long codeb...@inbox.lv wrote: ...that problem is solved by using SHA1. The other issue, which is specific to specific situations, is whether the hash alone is sufficient to protect against malicious alteration of the repository. In the first case it would seem SHA1 is still acceptable although it's increasingly becoming apparent SHA1's days as an ideal hash have come and gone. In principal it would be possible to update fossil at some point to use a different hashing mechanism, and export a sha1-based repo to a new one. They wouldn't be compatible after that, but nothing in the overall design really prohibits it. There is arguably a micro-window of opportunity for corruption during conversion unless the conversion is tested both ways, but that would be manageable. There are cosmetics, such the hard-coded word SHA1 everywhere (and related length/syntax constraints), but the underlying SCM model is independent of the hashing algorithm used (or the storage used to store the blobs, for that matter). A simple CRC32 would work just as well for most purposes (though of course nobody's suggesting that). That said, while the change is simplein the abstract, SHA1 is pretty well-entrenched into the source code, so it would be an invasive port/change. Understood. In the second case I think it's possible to prevent and/or detect of attacks on the repo with very minimal workflow adjustments I outlined earlier, or something similar to that, without any changes to fossil at all. i'm still waiting for someone who has a head for security-related coding to volunteer for that ;). It's a workflow issue. No coding is required: 1. Create a new repo 2. Add a public key used for code signing 3. Optionally add a cross-signature of your code signing public key 4. Add all the source code you want to check in 5. Add detached signatures for all source code you checked in 6. fossil commit After that you simply detach-sign all source code before committing. From then on, anybody who can access the repo can use the public key you saved in the repo to verify any individual source file based on the associated detached-signature. The key owner (or anyone else who has the pubkey the key owner cross-signed with) can user the cross signature to verify the public key in the repo hasn't been tampered with. In the absence of the cross-signing pubkey, or if you don't want to take the initial step of cross-signing the code signing key, anyone can verify the pubkey type, length, and fingerprint with the pubkey that was initially checked in and compare that to the verification output of any piece of source. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
On Tue, Aug 20, 2013 at 09:28:00PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 9:03 PM, John Long codeb...@inbox.lv wrote: My understanding is you already compute checksums on commits. At a lot of places. Blob content is referenced by its content SHA1, so any change there invalidates it. A commit contains two checksums: one is the checksum of the content of the checkin manifest (basically: the formal list of changes, but not the changes themselves, similar to a PGP signature). The second one is a checksum of the names/sizes/content of each file in the commit manifest (basically: each file that changed). Fossil ignores/skips over/elides the PGP wrapper for purposes of checksums. and If that's true I would say if you verify any signed commit (and again it's not clear how multiple files are handled unless every file is signed individually) The signing happens at the commit level, and a commit contains N files. If I understood what you wrote, the checkin manifest is some kind of meta data about the commit and the second one above is *one* checksum on the list [a file of?] of names/sizes/content of each file in the commit manifest? Which also sounds sortof like metadata and data combined. From a digital signature view I would say each user component of a checkin (each source file and everything I want to include in this commit) ought to be signed individually if only for the practical reason there isn't any meaningful alternative. If I got what you wrote then the signature you have today is on meta-data, which is derived from the commit components. That seems to be a suboptimal or even wrong way to employ digital signing because nobody is responsible for this, it's done in software, on some metaobject that I have no direct control over- as if the key owner is assigning perfect trust to fossil to do the right thing. That means fossil is authenticating the checkin, which is not useful or meaningful. Digital signing means I certify that I wrote this. This thing itself, and not something derived from it. It might be clumsier for fossil, but it seems to me that if you choose to employ digital signatures on a project they ought to be required and verified individually on all components of a checkin. This will have to be a detached signature in the case of binaries. And if I can guess what you're thinking it's probably not worth it I might be inclined to agree. It is something that doesn't scale when a commit is at a higher level than one piece of source code. This is heavy-duty stuff to be used when you need to know with virtual certainty that person X updated a specific file. If you don't need to know that then this is overkill and a lot of work. If you do need to know it there isn't any other practical way to accomplish it. If all this is accurate then I don't understand how it works in practice today. Is fossil signing metadata? Who is signing it? then you should not have to do anything further, maybe not even note that it's PGP signed. The PGP signing is about authenticating that some user X is really the guy who did this update. Once that has been established it goes into the repo and nothing more has to happen. There's the problem for the current architecture: when it goes in the repo. Let's say for a second that one of the signed commits in Fossil's repo is currently invalid. Now we add this feature. The next time fossil is rebuilt, it would have to reject that commit, which would break the whole rebuild, effectively leaving us with a repo we can't upgrade because PGP decided we shouldn't. From a practical standpoint it's exactly the same as a bad checksum. Whatever you do in that case is what you should do for a bad PGP signature. Saying PGP decided we shouldn't is the same as saying your SHA1 algorithm decided you shouldn't. This stuff is heavily used and if you're going to use it you have to rely on it. If you can't rely on it you shouldn't be using it in the first place. Any code can break. In practice, we don't see that gpg or PGP signatures have bugs any more than SHAx implementations do. Fossil has no useful recovery strategy there other than to not let you rebuild the db (==update its schema to a newer version, which also rebuilds all derivable/calculable data contained in the repo). i think flag and accept would be the best Fossil could sanely do. What i can envision is, assuming validation has hypothetically been added: a) show yellow/green/red in the timeline, and something similar in CLI b) a 'pgp' command which takes a list of UUIDs to verify. But i don't think Fossil is capable of rejecting failures without seriously endangering backwards compatibility in the case of an age-old signature (==predating this feature) which is invalid. Maybe it could, or maybe it could offer an option/flag to allow failed sigs or not. i'm not in any way, shape, or form a cryptographer, i'm just thinking out loud here :/. I hear
Re: [fossil-users] commit signing
I need to go back in the archives and see where I can find an example of this but in the meantime to ask the obvious, is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? On Tue, Aug 20, 2013 at 08:00:41PM +0200, Gour wrote: On Tue, 20 Aug 2013 18:41:39 +0200 Stephan Beal sgb...@googlemail.com wrote: However... i don't want to move this to the trunk until i hear some feedback from the devs whether this is the optimal solution or whether something like a simple PGP would do. Sure, let's hear what others can say... Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
On Tue, Aug 20, 2013 at 08:32:21PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 8:07 PM, John Long codeb...@inbox.lv wrote: I need to go back in the archives and see where I can find an example of this but in the meantime to ask the obvious, is fossil verifying the signatures as part of the commit process or does fossil simply carry the data so the signature can be verified manually? It simply carries them over and accounts for them while parsing manifests. If there is code to verify them, i haven't seen it yet. If you're working on flagging PGP commits then it would be really nice to say PGP in red if the signature doesn't verify or green if it does or something like that. Otherwise saying PGP on a commit does more harm than good imho. Personally for hosted projects I'd like to see a feature that has an option to verify the signature on commits before committing them as a protection against unauthorized access to the repo (weak passwords, http instead of https etc.) /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit signing
On Tue, Aug 20, 2013 at 08:43:36PM +0200, Stephan Beal wrote: On Tue, Aug 20, 2013 at 8:39 PM, John Long codeb...@inbox.lv wrote: If you're working on flagging PGP commits then it would be really nice to say PGP in red if the signature doesn't verify or green if it does or something like that. Otherwise saying PGP on a commit does more harm than good imho. Personally for hosted projects I'd like to see a feature that has an option to verify the signature on commits before committing them as a protection against unauthorized access to the repo (weak passwords, http instead of https etc.) Yeah, i left the word signed in the hopes that it didn't apply approved. Patches are of course welcomed for validation, provided they don't require 3rd-party deps (extern deps mean the feature must be optional, e.g. SSL). I don't code in C, not even with a gun held to my head or I would be glad to try to help. fossil is a fantastic project. I believe there is a library put out by the gnupg project that is used specifically for stuff like email clients to interface to gpg (the open source version of PGP) that should have a very simple interface. I think it is called gpgme (gpg made easy) IIRC. I think it's not something you have to link and you should be able to tell if it's present or not. If a commit is signed and can't be verified, it could be highlited in PGP yellow. Green verified, red doesn't verify. That would be amazing. What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is seen at checkin or on rebuild)? I haven't used gpg/pgp with fossil but I use gpg a lot. Thinking out loud one workflow would be something like: get a commit ready and sign each piece of code/whatever push or commit fossil sees the signature field (easily detected by standard header): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Stephen Beal! -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSE7rJAAoJEPh15eraZbwERKIIAMG6gup+QX0s5of4ovxqjuQA IME1rUexfBxVbi5CQGLuk/SvZYotPzbVPcWBsCVS9FW4kaP/19zP1Wpgm+SGU88/ +yOHrn7QBXNeti7lmyhFFCOoV4PqpNhlklTqASz1Ga9pm4ZhjJ1YYUfPXV0V2LDM 0VugnJCYq/QDLXZXI0z9F2/FULjgv7OfUN0dCsjwRwyzBip1tOoWIseG13en1uLm exm8RLUNbzjE7LcYV/jUwrOzCmnFjIqSb3l6CfhPuBeLonKzO0W+jVy/QHKxY2bE hS4dMu3vM6Op7cOfiB4bdT1jMWyIntyOBvZK0+18jRmfKRHJaSzNeSd5noZrCUI= =xA6W -END PGP SIGNATURE- verifies it and commits or fails it and doesn't commit. There are two kinds of signatures, clearsigned like above or detached (separate file). To process a clearsigned object you strip the headers. Otherwise you validate each file in the commit against filename.asc. That would make things a lot simpler because once the commit hits the repo it is a known-good commit. If it gets corrupted it's the same big problem as any corrupted commit. But this is on a single-file level. I do not know how you can sign commits that contain more than one file. Should it then reject the whole db? i don't think we have a recovery strategy if they fail. The best we could do is flag them in the timeline as passed/failed/unchecked, i think. My understanding is you already compute checksums on commits. If that's true I would say if you verify any signed commit (and again it's not clear how multiple files are handled unless every file is signed individually) then you should not have to do anything further, maybe not even note that it's PGP signed. The PGP signing is about authenticating that some user X is really the guy who did this update. Once that has been established it goes into the repo and nothing more has to happen. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to ignore UNIX executables?
On Sat, Aug 17, 2013 at 03:11:34PM +0800, Michael Richter wrote: On 15 August 2013 21:23, John Long codeb...@inbox.lv wrote: Hi, is it possible to ignore UNIX executables? I want to do an addr on a directory tree but I don't know how to tell fossil not to track the binaries since they have no naming pattern. Until now I've been living with it but it is very annoying and time for me to ask. Help! You can always use Marc Simpson's fsl http://fossil.0branch.com/fsl/homewrapper script around fossil to do whatever workflow you like. If you need help writing a script for this, drop me a line and I'll gladly work one out with you. I'll look at this link and thanks for the offer :-) /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How to ignore UNIX executables?
Hi, is it possible to ignore UNIX executables? I want to do an addr on a directory tree but I don't know how to tell fossil not to track the binaries since they have no naming pattern. Until now I've been living with it but it is very annoying and time for me to ask. Help! Sorry if this appears twice. I didn't see whether you have to sign up to post to the list and I didn't see my message in the archives so I signed up and sent it again. Thanks, /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to ignore UNIX executables?
On Thu, Aug 15, 2013 at 03:35:08PM +0200, Stephan Beal wrote: On Thu, Aug 15, 2013 at 3:23 PM, John Long codeb...@inbox.lv wrote: Hi, is it possible to ignore UNIX executables? I want to do an addr on a directory tree but I don't know how to tell fossil not to track the binaries since they have no naming pattern. Until now I've been living with it but it is very annoying and time for me to ask. Help! There is no mechanism for it to exclude binaries and doing so would break the _only_ reason Fossil supports the +x bit at all: configure scripts are normally marked as executable (and that was the only reason Richard originally agreed to add +x support). One way to do it is to add everything: fossil add . and then: fossil status and look for the binaries. Then do: fossil rm those...files and they won't be included in the commit. That's what I have been doing. But it seems very wrong to have to play games with this. Thanks for the info. /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to ignore UNIX executables?
On Thu, Aug 15, 2013 at 03:17:32PM +0100, David Given wrote: John Long wrote: [...] That's what I have been doing. But it seems very wrong to have to play games with this. If you know the names of the binaries in advance, it should be possible to add each one to the ignore list individually --- e.g. fossil's own looks like this: compat/openssl* compat/tcl* fossil fossil.exe Thanks. Actually I just backquote a find command to add and remove groups of files I'm not doing it totally manually. But it is such a pain in the ass I was sure this was already supported and I was just missing something. I guess Richard works mostly on Windows and can ignore *.exe ;-) /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to ignore UNIX executables?
On Thu, Aug 15, 2013 at 10:58:52AM -0400, Richard Hipp wrote: On Thu, Aug 15, 2013 at 10:53 AM, Stephan Beal sgb...@googlemail.comwrote: I guess Richard works mostly on Windows and can ignore *.exe ;-) IIRC (maybe wrong) he works more on Mac. I work on Linux. Linux has been my primary desktop since 1993 with Yggdrasil Linux kernel version 0.99. I usually tote a Mac Air with me when I travel because it is light-weight and the WiFi works well in hotels and airports. Other than that, I only use Macs and Windows machines for testing. Ok so would you mind explaining how you deal with this issue? Are you manually adding stuff, or just adding .c and .h files, or ?? Thanks, /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to ignore UNIX executables?
I didn't really understand your message. I was not asking for any change to the way fossil works. I was only asking if it was possible to ignore executables. If it was I would set whatever setting was needed and live with the consequences. It does seem surprising to me that this is not a much requested capability. But then again I do about 1% of my development on UNIX and 99% elsewhere so a lot of things in UNIX seem strange to me and I probably miss the point a lot. On Thu, Aug 15, 2013 at 11:37:22AM -0400, Ron Wilson wrote: On Thu, Aug 15, 2013 at 10:14 AM, John Long codeb...@inbox.lv wrote: That's what I have been doing. But it seems very wrong to have to play games with this. It's not a one-size-fits-all situation. Depending on your project, you may need to version executables. For example, the build process for the projects I work on include shell scripts in addition to the makefile. Yes, they could be executed with bash somescript, but that is not how the process geeks want to do things, so we live with it. And someone already mentioned about configure. Also, in our Tools project, the built executables are versioned so that updates can be easily pulled with out the need to rebuild it locally. Yes, there are other ways we could do this, but why have 2 versioning systems? Also, we don't want to use the IT department's software deployment system as it would require getting IT's process geeks involved. Whether Fossil defaults to ignoring executables or not ignoring, there will still be a need to tweek this. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Official approved way of moving a repo?
I just finished deleting a few dozen repos since I moved a bunch of source code to another machine and fossil refused to like it. After that I found a discussion on the mailing lists about test-move-repository. Not a big deal since this was all test stuff but I would like to know what the official approved way is to let fossil know a repository has been moved. For example: old repo was in /home/user/code/project copied the project directory including the repo to /newmachine/differentuser/programs/newplace What command(s) should I use to tell fossil the repo now exists in /newmachine/differentuser/programs/newplace? Thanks /jl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
