Re: [fossil-users] Multiple Projects in one Repo
Thus said Oliver Friedrich on Sat, 12 Sep 2015 12:34:21 -: > What I really would like to have is to gather multiple such small > projects in one repo file, so instead of having one ROOT check-in, > having one ROOT for each project. I know that would make developing > fossil a bit harder, but I think it would be a great feature and that > not I'm the only one who would use this. You mean like this: assume you have two Fossils, master.fossil and project.fossil. You want to combine the projects into a single Fossil but retain an independent timeline for each: $ echo "SELECT 'UPDATE config SET value = ''' || value || ''' WHERE name = ''project-code'';' FROM config WHERE name = 'project-code';" | fossil sql -R master.fossil | fossil sql -R project.fossil $ fossil pull --once -R master.fossil project.fossil Now, master will have two independent timelines, one from each project. You'll then want to rename one of the trunks (and maybe give it an intentional color too) in one of the timelines to something else or you'll get a warning about there being two open leaves with the name of trunk (even though technically there really isn't a fork in this case). > But I guess that implementing this could be much harder, especially > visualizations in the web-frontend. The web-frontend can handle visualizing this just fine I think. What may take some getting used to is that the files and checkins will not have common ancestors. Also, if you have the same exact filename (and path) in one ``sub-project'' that exists in another, the Files display in Fossil might be tricky to navigate. But otherwise, it will probably work well. Here's an example: http://fossil.bradfords.org:8080/timeline But, the same filename exists in all three timelines, but has different content. Files only shows the last (due to tip): http://fossil.bradfords.org:8080/dir?ci=tip You could certainly change the Header to have multiple links to the various files of a given ``sub-project'' like: Trunk Files: http://fossil.bradfords.org:8080/dir?ci=trunk Project1 Files: http://fossil.bradfords.org:8080/dir?ci=project1 Project2 Files: http://fossil.bradfords.org:8080/dir?ci=project2 What if you need files from different projects at the same time in the same tree? Well, you'll have to resort to multiple opens (and maybe --nested) for that. Andy -- TAI64 timestamp: 400055fa4bb3 ___ 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] Multiple Projects in one Repo
On 16 September 2015 at 21:56, Steve Stefanovich wrote: > Isn't the main annoyance the need to commit two times, one in nested > checkout and one in the 'root' repo, and to try to keep timeline order in > both? > > How do you guys manage that - prevent committing/cloning to root and > always use sub-repos? There's only one commit, in the sub-repo, unless I change something in the root repo, but that's pretty rare for me. ../Dave ___ 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] Multiple Projects in one Repo
Isn't the main annoyance the need to commit two times, one in nested checkout and one in the 'root' repo, and to try to keep timeline order in both? How do you guys manage that - prevent committing/cloning to root and always use sub-repos? Original Message From: Warren Young Sent: Tuesday, 15 September 2015 03:58 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Multiple Projects in one Repo On Sep 12, 2015, at 9:54 AM, Oliver Friedrich wrote: > > with nested repositories my administration overhead would exceed even the > single repository solution, right? The alternative to managing just one .fossil file is managing just one directly full of .fossil files. Is that really such a big difference? Note that “fossil serve” works the same when pointed to a directory full of fossils as it does when pointed at a single fossil, with the exception that the URLs are all one directory deeper. There are two annoyances currently involved in managing nested repositories, which could in principle go away: the need to explicitly open the sub-repositories every time you open the primary, and the need to pass --nested to bypass the checks Fossil does for a parent containing .fslckout (a.k.a. _FOSSIL_). Git solves this problem more elegantly with the submodule: https://git-scm.com/book/en/v2/Git-Tools-Submodules In short, the main project simply declares that it needs other projects by URL. When you clone the main project, Git also clones the submodules into the correct place within the parent’s tree. I use nested checkouts myself, though probably for a different reason than you’re proposing. I have a top-level repository with many branches for older versions of the software, and all versions need to share a single set of Fossil-managed resource files. These shared resource files must be versioned separately from the main repository files, but the current version must always be present underneath the main repository branches. If I have three branches checked out, I need three additional nested checkouts of the shared repository. It would be very nice if I could just open each branch, and have the subproject’s repo opened in its correct place, automatically. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Interesting video on Google repository
On Sep 16, 2015, at 12:13 PM, Scott Robison wrote: > > https://www.youtube.com/watch?v=W71BTkUbdqE The point I took from that that seems most applicable to Fossil is the idea that “workspaces” (i.e. local clones) are not complete copies of the entire repo’s history. In Google’s case, it’s because it would simply be unfeasible, at 86 TB, yet would include millions of old files that don’t even exist at the tip of the trunk any more. While there probably isn’t anyone on this list with a Fossil repo anywhere near this size, the lesson remains: you probably don’t actually need the entire repo history in your local clone. Some months ago, the thread “Fossil 2.1: Scaling” thread touched on this: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019952.html In that thread, I proposed that the default mode of “fossil clone” be to include only the last N weeks of work on each open branch. The idea being, you rarely need more than that except for archaeology work, at which point Fossil could go back to the repo it cloned from and import more of the history. The amount of history per branch should be configurable, and of course it should be possible to disable the limit, so that you get a complete clone, which is nice for distributed backups. (I’m reminded of a Linus Torvalds quote, where he said he never did backups, because his code is already distributed all over the world.) Has there been any movement on that front? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Stash-cat
Hi. I pushed http://fossil-scm.org/index.html/info/533f8b6aeacb554f on its own branch for review (philosophical/ui, or errors/updates); otherwise, it's ready for integration. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Interesting video on Google repository
https://www.youtube.com/watch?v=W71BTkUbdqE -- Scott Robison ___ 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 embed image in project home page or wiki pages?
On Tue, Sep 15, 2015 at 9:24 PM, The Tick wrote: > > > That is one of the features that I was looking for. How to get the URL for > that to put on the 'home' page is one of my next tasks. I doubt that most > windows users would explore fossil's interface (and understand it enough) > to click 'files' then click the weird check-in id to get to the ZIP > download button. At this point I'm assuming I can just copy that URL and > duplicate it on my home page. Yes, you can simply copy that URL to the home page. You will need to update it each time you make a release. In theory, it is also possible to craft an URL that would also provide a zip of the latest with a particular tag, such as "release". Not sure if this is a good idea, but it would eliminate the need to update the home page for each release. (Personally, I prefer to explicitly update my download page for each release.) > I'll have to explore that. It's just one image to get an idea of the app's > GUI. To have a file appear in only one version in the repository: fossil add path/to/file fossil commit -m 'comment about file being added' # the ID of this commit is the version containing the file. fossil rm path/to/file fossil commit -m 'Make it so this file only appears in the previous commit' You can add more than one file this way. To access the file, it will be necessary to refer to it using the commit ID of the version containing the file. (Alternately, you can use the artifact ID of the file.) > Again, thanks for your help. You are welcome ___ 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] Why Hash
On Sep 16, 2015 3:24 AM, "Michal Suchanek" wrote: > > On 16 September 2015 at 05:16, Scott Robison wrote: > > But GPG could solve any weaknesses with Fossil's use of SHA-1, though. It > > won't prevent a determined party from deconstructing a repo, making whatever > > changes are desired, and rebuilding a believable facsimile that unwary > > parties might trust. The rebuilt repo could even have fraudulent GPG > > signatures attached just to make it feel more legit to people who don't > > really check such things. > > It has been pointed out that when using GPG to sign checking only the > manifests are signed and what links the manifests to the rest of the > content like actual file blobs or previous checkins are the weak SHA-1 > hashes. Right, I didn't mean "GPG can fix this today with the current implementation in fossil". Just that it could be used to authenticate the source of global repo state. If we accept that sha1 is used for nothing more than identification and a way to validate an artifact as having not been accidentally modified, then clearly another means of authentication is necessary if it is a required feature. I accept that all artifacts should be signed for such a feature and that it is not happening at this time. > > So while it is possible to use PGP with fossil it gives only a false > sense of security until fossil itself uses crypto grade hash to link > its internal articact structure. > > Using a stronger or configurable hash for the internal linking of > artifacts would result in ability to verify the authenticity of a copy > of a signed repo even from unknown source so long as the signatures > are valid. > > As actual signed repos are rare this is not really strong use case. On > the other hand, they may be rare because there is no real point. I think they are rare because signing and verifying is a pain and we trust the official versions of repos. Arguably we should not. Even if GPG were being used completely and effectively, how can we be sure someone's private keys weren't compromised? We've talked on list before about how (with regard to computers) nothing is perfect, everything is statistically flawed in some way making it less than 100% guaranteed to work properly. I think fossil's (and other dvcs) use of sha1 fits in this category. It isn't perfect, but it is close enough for the use case. > > Thanks > > Michal > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Why Hash
On 9/16/15, Noam Postavsky wrote: > On Wed, Sep 16, 2015 at 1:38 AM, Stephan Beal > wrote: >> (i will naively assert) "impossible" that both the sha1 and md5 could >> both be made to match in a collision of a non-empty blob. > > This might be too optimistic. According to Antoine Joux in > "Multicollisions in Iterated Hash Functions. Application to Cascaded > Constructions" [1] > > > [1] http://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19 Fascinating. Thanks for the link! -- D. Richard Hipp d...@sqlite.org ___ 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] Why Hash
On Wed, Sep 16, 2015 at 1:38 AM, Stephan Beal wrote: > (i will naively assert) "impossible" that both the sha1 and md5 could > both be made to match in a collision of a non-empty blob. This might be too optimistic. According to Antoine Joux in "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions" [1] A natural construction to build large hash values is to concatenate several smaller hashes. For example, given two hash functions F and G, it seems reasonable given a message M to form the large hash value (F(M)||G(M)). In this construction, F and G can either be two completely different hash functions or two slightly different instances of the same hash function. If F and G are good iterated hash functions with no attack better than the generic birthday paradox attack, we claim that the hash function F||G obtained by concatenating F and G is not really more secure that F or G by itself. Moreover, this result applies both to collision resistance, preimage resistance and second preimage resistance. [...] Another generalization of the above attack is also worth noting. In [14], B. Schneier described a different way of building a long hash from a hash function F. In this method, F(M) is concatenated with G(F(M)||M) (or G(M||F(M))). At first view, this is more complicated than the F||G construction. However, the very same attack can be applied. [...] One can also study a related question, how does the security of the concatenated hash F||G behaves, when F and G have non-generic attacks better than the birthday paradox collision search? In that case, can F||G be significantly more secure than the best of F and G? [...] if G also admits a shortcut attack (as in section 3), it is unclear whether the two shortcut attacks may be used together to improve the composed attack against F||G. Yet, some other type of attacks against G can be integrated into a better composed attack on F||G. ... Thus, it is safer to assume that F||G is essentially as secure as the best of F and G, no more. [1] http://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19 ___ 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] Why Hash
On 16 September 2015 at 05:16, Scott Robison wrote: > On Tue, Sep 15, 2015 at 7:46 PM, Warren Young wrote: >> >> On Sep 15, 2015, at 7:01 PM, Scott Robison >> wrote: >> > >> > I think calling it a non sequitur is not completely fair >> >> Stephan stated that Fossil isn’t doing cryptography, therefore SHA-1 >> doesn’t have to be replaced. Cryptography and message authentication are >> not the same thing. >> >> It’s like pointing out that the bald tires on the car do not need to be >> replaced because we don’t require that the car be able to climb trees. >> >> > It wasn't intended to provide cryptographic security >> >> I’m probably just being pedantic, but now you’re doing it, too. >> >> “Cryptographic security” implies encryption, which is not being done here. >> >> The proper phrasing is “cyptographically-strong message digest algorithm.” >> The reference to cryptography is only an indicator that the use of a given >> MD algorithm can be used with some given cryptosystem without compromising >> its integrity. > > > As I understand "cryptography" to be defined it means "the practice and > study of techniques for secure communication in the presence of third > parties". If that is correct, message authentication is most assuredly a use > of "cryptography to securely identify authenticity". If I'm using a term > incorrectly, my apologies. > >> >> > It is more likely to detect accidental corruption than deliberate >> > corruption. >> >> I thought that’s what the MD5 bits were for. >> >> My sense from reading the file format wiki page is that the SHA-1 bits >> ensure that blob B, which is intended to appear in the timeline between >> blobs A and C, was almost certainly inserted into the database at time T_b, >> where T_a <= T_b <= T_c. That is, it is primarily a guarantor of checkin >> ordering. >> >> That’s why I’ve been framing the risk as one of potential insertion of a >> timeline item way in the past. >> >> That may be a bogus risk for other reasons, though, since you’d also have >> to work out how to change all the deltas. > > > The SHA-1 bits ensure (virtually guarantee) that blob B has a unique > identity so that two contributors don't allocate ID 42 at the same time > creating a collision in commit IDs. Artifacts are unordered and can > originally come into a repository from any source in any order. It is > primarily a guarantor of checkin identity, and the individual cards in the > manifest control timeline order, date, time, author, etc. > >> >> It’s also occurred to me since my previous post that all the work needed >> to generate a bogus SHA-1 hash for an HTTPS cert only has to be done once, >> at which point you now have a reusable cert good for months or years. The >> work needed to attack a single timeline entry in Fossil is a one-shot deal: >> to attack two different nodes in the timeline, you need to do 2x the work. > > > Given that the commit ID is a hash of the manifest, and most of the cards in > the manifest are F cards, in theory all you have to do is find a useful > collision with the SHA-1 hash of any file artifact. If you could modify one > file without changing its SHA-1 hash, everything else in the database would > still match its hash. Of course, if it is too far back in the history > (probably even a single merge behind tip) it may never be noticed because > the project has moved on. And the difficulty still exists of getting it into > the master repository. > >> >> > simply gaining commit access to the master repository as mentioned the >> > other day would not be adequate; the maliciously modified artifact would be >> > rejected by fossil >> >> I’m no expert in Fossil’s inner workings, and I have no interest in trying >> to attack it. >> >> I’m just aware that Bruce Schneier and Google’s crypto geeks know things I >> do not, and I use that awareness to guide my own design decisions. The last >> hash-based system I designed used SHA-256. :) > > > I have a lot of respect for Schneier. I would not consider using SHA-1 in a > security sensitive environment today. This use is less about security and > more about non-cryptographic hashing, where an (at one time) cryptographic > strength hash happened to be satisfactory for the needs at hand. > >> >> > I find it far more likely that someone would fork the repo and >> > contaminate it that way, rebuilding it from scratch, and finding ways to >> > induce parties to use *that* version of the library instead of the blessed >> > repo. >> >> Clearly so. >> >> Always attack the weakest link first, if possible. >> >> > * ethernet uses a 32 bit CRC; how much internet traffic goes through >> > ethernet? Can't really change that because of backward compatibility. >> > * rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I >> > remember correctly). Can't really change that because of backward >> > compatibility. >> >> That’s why TLS exists. >> >> TLS doesn’t solve any weaknesses with Fossil’s use of SHA-1, though. It >> just pre