Re: [fossil-users] Shunning files with confidential information - renames, removed files etc.
On Mon, Aug 17, 2015 at 1:07 PM, Graeme Pietersz gra...@pietersz.net wrote: All the files concerned have a distinctive filename pattern (all start the same) and would only ever have been in one of two directories in any version. Not sure if that helps. Fossil does not shun by filename, but my hash value, so you'll need to find all hashes of all versions of those files and shun those. It is likely far simpler to recreate your repo without the compromised data (and count it as a lesson learned for future repos). That said, i have never used shunning, and it is possible (not sure!) that shunning the first version of a file will affect (shun) following versions, as they derive from it and it's conceptually impossible to derive from something which is no longer in the repository. Perhaps someone who's better-versed in shunning can enlighten us on that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Shunning files with confidential information - renames, removed files etc.
Nice. Is it possible to trim the results to only a specific file using a raw SQL query or TH1? Or is it quicker to just parse fossil test-whatis-all artifacts.txt output? Can I enter multiple artifacts(comma or space delimited) in the shun ui or only 1 at a time? Thanks On Mon, Aug 17, 2015 at 6:08 PM, Kees Nuyt k.n...@zonnet.nl wrote: On Mon, 17 Aug 2015 16:37:41 +0530, Graeme Pietersz gra...@pietersz.net wrote: I have a Fossil repo that I expected to only work on myself. I have files containing confidential information and I now need to allow someone else developer access (so clone, push and pull as a minimum) to the repo. I need to do two things: 1) remove past versions of one file that used to contain confidential information (it was removed in the latest commit). Does that mean shun, rebuild and then add again? How do I ensure all past versions are removed? This file has also been renamed so I need to check versions using the old path are sunned as well. Yes. 2) ensure that I have never committed another file, and, if I have, shun it completely. 3) shun two files that have been removed, but old versions of which are in the repo. They are not hard to find in the UI. All the files concerned have a distinctive filename pattern (all start the same) and would only ever have been in one of two directories in any version. Not sure if that helps. I don't have an answer to all of your questions, but I suppose the fossil test-whatis-all command, with some grep or awk magic will help you identify the artifacts to shun, and verify the result after the clean-up. -- Regards, Kees Nuyt I would be very grateful for any help. Graeme ___ 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] Shunning files with confidential information - renames, removed files etc.
On Mon, 17 Aug 2015 16:37:41 +0530, Graeme Pietersz gra...@pietersz.net wrote: I have a Fossil repo that I expected to only work on myself. I have files containing confidential information and I now need to allow someone else developer access (so clone, push and pull as a minimum) to the repo. I need to do two things: 1) remove past versions of one file that used to contain confidential information (it was removed in the latest commit). Does that mean shun, rebuild and then add again? How do I ensure all past versions are removed? This file has also been renamed so I need to check versions using the old path are sunned as well. Yes. 2) ensure that I have never committed another file, and, if I have, shun it completely. 3) shun two files that have been removed, but old versions of which are in the repo. They are not hard to find in the UI. All the files concerned have a distinctive filename pattern (all start the same) and would only ever have been in one of two directories in any version. Not sure if that helps. I don't have an answer to all of your questions, but I suppose the fossil test-whatis-all command, with some grep or awk magic will help you identify the artifacts to shun, and verify the result after the clean-up. -- Regards, Kees Nuyt I would be very grateful for any help. Graeme ___ 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] Shunning files with confidential information - renames, removed files etc.
On 17/08/15 16:47, Stephan Beal wrote: Fossil does not shun by filename, but my hash value, so you'll need to find all hashes of all versions of those files and shun those. I counted 71 versions of the most frequently changed of those files a lot easier to recreate. It is likely far simpler to recreate your repo without the compromised data (and count it as a lesson learned for future repos). It was my first or second fossil repo. Lesson definitely learned. That said, i have never used shunning, and it is possible (not sure!) that shunning the first version of a file will affect (shun) following versions, as they derive from it and it's conceptually impossible to derive from something which is no longer in the repository. Perhaps someone who's better-versed in shunning can enlighten us on that. If anyone can confirm either way it would help a lot - at least I would know the worst. I also think it needs to be clearly documented on the wiki page - someone could easily leak secrets by getting this wrong. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Graeme Pietersz http://moneyterms.co.uk/ http://pietersz.net/ ___ 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] Search feature
On Mon, 17 Aug 2015 18:04:37 +0200, sky5w...@gmail.com wrote:
I read the search feature is in a trial stage.
Can it be expanded to search in actual source files?
Now using the browser and only per file. Or of course in an external tool
in my checkout folder.
Thanks for Fossil.
until the time comes where fossil supports grep out of the box I'm using
the following qd shell script. provided you are on linux/unix/macosx this
should
work for you (N.B.: I'm using `ksh' rather than `bash' (or `zsh'). to make
it work with `bash' you'd need to replace the `print' command by `echo' or
a suitable `printf' call (and find out what the equivalent of `print -r
--' in bash is ... probably some similar `printf' construct). in any case
you get the idea
sure it is inefficient (dumps all revisions of the file and greps through
all of them ...), but it works OK for me.
8--
#!/usr/bin/env ksh
#--
# purpose: grep through all revisions of one or more files from a `fossil'
# repository.
#
# calling syntax:
#
#fslgrep grep-options pattern file {file ...}
#
# where `grep-options' is passed to `grep'. options taking arguments for
the
# time being must *not* contain spaces (or the whole option string must
# be enclosed in quotes).
#
# example:
#
# fslgrep '-C 5' foo bar.txt
#
# will look for `foo' in all revisions of `bar.txt' and report them with a
5 line context.
#--
function getHashes { # `fossil finfo -W 0' output
print $1 | awk '
NR == 1 {next}
/^[0-9]/ {
sha1 = substr($2, 2, length($2) - 2)
print sha1
}
'
}
#--
# define default grep options to be used:
options=--colour=always
# append user defined options and extract grep search pattern
for i do
[[ $i == -* ]] {
options+=$i
((optcnt++))
}
done
((optcnt 0)) shift $optcnt
pattern=$1
shift
for i do
timeline=$(fossil finfo -W 0 $i)
(($? == 0)) || continue
hashes=$(getHashes $timeline)
for h in $hashes; do
rep=$(fossil cat -r $h $i | cat -n | grep $options $pattern)
(($? == 0)) {
print -- \n** $i [$h] **
print -r -- $rep
}
done
done
8--
HTH
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Search feature
I read the search feature is in a trial stage. Can it be expanded to search in actual source files? Now using the browser and only per file. Or of course in an external tool in my checkout folder. Thanks for Fossil. ___ 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] Self Signed Certificates
Hello, Thank you for the quick response. Sorry it took me so long to respond. On 16/08/15 23:37, Jan Danielsson wrote: I assume you aren't using client certificates; but I'll ask anyway: Are you using client-certificates to achieve mutual authentication, or is it a server-only certificate? It is a server only certificate. We could check for expired certificates on the client, but note that the important question is whether the server accepts expired certificates. (The client can be manipulated, so that check can't be trusted for access control). What are you using to serve the repository over SSL? stunnel? Apache? Other? Nginx with openssl. There is no option in the server config to use plain http and users are redirected to https. It was a while back, but I have a vague memory of fossil complaining when my certificates expired; though I use mutual authentication -- and I'm not entirely sure I remember correctly. I am quite sure that fossil did not warn me - I accessed it from several machines and only noticed the certificate had expired when I used a browser. If you didn't add the CA as a trusted CA in fossil, then it should have asked you to trust the server certificate. I'm not sure how the check is done; if it only compares name fields it's not good. Unfortunately I'll be a little busy the next few days, but send me a ping in a week or so if it still remains a mystery and I'll take a closer look. Fossil definitely did not ask me to trust the new certificate - it is a completely different certificate too. Thank you for your offer of help. Saul Hazledine ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] permuted index doc-page: request for feedback (was: Remove redundant shun links from doc page.)
[ conversation about appearance of permuted index page from a while ago ] On 22 June 2015 at 20:11, Ross Berteig r...@cheshireeng.com wrote: On 6/22/2015 10:46 AM, sky5w...@gmail.com wrote: I agree we all think differently, but the output should collate the descriptions while keeping only a single common link. The difference with the wiki 'keyword in context' is I can see the duplication. The auto doc page infers many unique links. The whole point of a permuted index is to provide an alphabetical list of keywords, shown along with some context, and references (links) to where they appear. ... ok, I tried to do this earlier with a bit of effort, but my TCL-foo is too weak: how about displaying the permuted index (if that must be - I don't see the whole point of it, since there is a browser 'search' function anyway, but hey :-), but display canonical links in bold. The section header could then be something like Permuted index, (canonical titles displayed in bold). Is that an idea? my Tcl-foo is less weak now, and the canonical titles in bold was tried in [2a8dd751] (http://fossil-scm.org/index.html/doc/2a8dd751/www/permutedindex.html for an impression). After feedback that the canonical titles stick out too much now, a separate list of canonical titles was tried in [66920879] (http://fossil-scm.org/index.html/doc/66920879/www/permutedindex.html for an impression - canonical titles follow the original permited index). Another suggestion was to move the list of canonical titles in front of the original permuted index - which sounds perfect to me. Is this something you like? Feedback is welcome. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
