Re: how to output yara rule file information in C language

[Wesley Shields]

metas is a pointer to a YR_META structure 
(https://github.com/VirusTotal/yara/blob/master/libyara/include/yara/types.h#L225).
 You can see how yara handles it when printing metadata about a rule here: 
https://github.com/VirusTotal/yara/blob/master/cli/yara.c#L1004

-- WXS

> On May 22, 2021, at 4:51 AM, 95 Daoge  wrote:
> 
> exampe:
> rule test_file
> {
>   meta:
>   author = "test"
>   description = "test mete display"
>   date = "20210522"
>   condition:
>   true
> }
> 
> use 
> yr_rule_metas_foreach(p, metas){
> printf("the message is :%s\n",metas->identifier);
> }
> i can only output :author descri and date but i want output 
> author = "test"
> description = "test mete display"
> date = "20210522"
> 
> is this possible?
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/000550e7-b234-45af-981f-0ab94464b4f8n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/AE4AD0BF-0223-48B8-AB72-5B0842956865%40atarininja.org.

Re: Yara rule: how to detect unsupported PE file for Windows 10?

[Wesley Shields]

The string you are highlighting is not indicative of a file running on Windows 
10 or not. That string is in the DOS stub, which is executed when you try to 
run the program under DOS. Why this particular file is not running on your 
system is a different issue but it has nothing to do with that string. In fact, 
that particular string is common across all delphi language executables. One 
option to detect it is to share a hash of the file so people can inspect it and 
see what is really going on.

-- WXS

> On Mar 9, 2021, at 7:36 AM, Unknown  wrote:
> 
> I wonder is exist a rule for detecting damage, corrupted, unsupported binary 
> file by Windows Loader?
> 
> Sometimes a file can not be executed on Windows. 
> 
> 
> 
> Sometimes a file can not be run on Windows 10:
> 
> 
> 
> How do you think it can be done by Yara rule to detect such of broken, 
> unsupported files?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/50d502d1-fae2-4e89-bca1-9309a85e103fn%40googlegroups.com
>  
> .
> 

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/4CD98139-8B8A-484E-B1A0-B6FC7217A3F5%40gmail.com.

Re: Learning YARA - hashes not being recognized?

[Wesley Shields]

This is a decision made by YARA. The underlying code which is doing the hashing 
is OpenSSL and that outputs using lowercase. Even if we switched it to all be 
uppercase we would have users complaining that they are expecting lowercase. We 
can't please everyone, so we just have to pick one and stick to it.

-- WXS

> On Feb 22, 2021, at 11:53 AM, Jonathan Livolsi  wrote:
> 
> Hi,
> 
> Ok, so because every hashing algorithm returns hashes in all uppercase and 
> yara requires all lower case, the only solution is for the user to manually 
> go through and change all uppercase to lowercase in the hash rather than have 
> either a tolower() functionality added to the yara rules or allow yara to 
> recognize both upper and lower case characters?  I feel like the industry 
> accepted standard for all hashing algorithms is that they are always in 
> uppercase and that should be expected, not the other way around.  I mean my 
> years of being a developer supports that gut feeling.  I am genuinely 
> confused by this decision to only accept lowercase and not upper for hashes.  
> Is this a virustotal issue or just a decision in the programming for yara?
> 
> 
> Jonathan
> 
> On Mon, Feb 22, 2021 at 11:33 AM Wesley Shields  <mailto:w...@atarininja.org>> wrote:
> See the warning at the top of 
> https://yara.readthedocs.io/en/stable/modules/hash.html 
> <https://yara.readthedocs.io/en/stable/modules/hash.html> - all hashes are 
> returned in lowercase.
> 
> -- WXS
> 
>> On Feb 22, 2021, at 11:30 AM, Jonathan Livolsi > <mailto:jlivo...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I am going through a lab to learn yara rules and have a simple problem but I 
>> am not seeing why this might be happening.  It is an online course and their 
>> support doesn't help with this kind of stuff.  I am just writing a simple 
>> rule to check the MZ bits and the file hash for MD5, SHA1, and SHA256.  
>> Nothing complicated about it.
>> 
>> In this screenshot I have in my simple yara rule a check for the first bytes 
>> of 5A4D and it works fine.  I commented out the hash checks and in the 
>> console you can see that I get a 1 returned because the rule matched.  
>> 
>> 
>> In this screenshot I uncommented the hash checks and the rule fails to 
>> match.  If I comment out the strings and the check in the conditions but 
>> leave in the hash (even just one at a time) the rule does not ever match.  
>> Yet in the powershell prompt to the right I have the calculated hashed that 
>> I used in the rule.  Am I missing something?
>> 
>> 
>> Thanks for the help.
>> 
>> 
>> Jonathan
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "YARA" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to yara-project+unsubscr...@googlegroups.com 
>> <mailto:yara-project+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> <mailto:yara-project+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org
>  
> <https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org?utm_medium=email_source=footer>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> <mailto:yara-project+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACYKFWoSshZ9m8%3DX2pT-f4S_sZpDTabdKCwk%2BTRCS3ngWSW34Q%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/yara-project/CACYKFWoSshZ9m8%3DX2pT-f4S_sZpDTabdKCwk%2BTRCS3ngWSW34Q%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/A63BBAF6-39ED-4215-B5C0-3CD069884922%40gmail.com.

Re: Learning YARA - hashes not being recognized?

[Wesley Shields]

See the warning at the top of 
https://yara.readthedocs.io/en/stable/modules/hash.html - all hashes are 
returned in lowercase.

-- WXS

> On Feb 22, 2021, at 11:30 AM, Jonathan Livolsi  wrote:
> 
> Hi,
> 
> I am going through a lab to learn yara rules and have a simple problem but I 
> am not seeing why this might be happening.  It is an online course and their 
> support doesn't help with this kind of stuff.  I am just writing a simple 
> rule to check the MZ bits and the file hash for MD5, SHA1, and SHA256.  
> Nothing complicated about it.
> 
> In this screenshot I have in my simple yara rule a check for the first bytes 
> of 5A4D and it works fine.  I commented out the hash checks and in the 
> console you can see that I get a 1 returned because the rule matched.  
> 
> 
> In this screenshot I uncommented the hash checks and the rule fails to match. 
>  If I comment out the strings and the check in the conditions but leave in 
> the hash (even just one at a time) the rule does not ever match.  Yet in the 
> powershell prompt to the right I have the calculated hashed that I used in 
> the rule.  Am I missing something?
> 
> 
> Thanks for the help.
> 
> 
> Jonathan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org.

Re: Machine Learning

[Wesley Shields]

I'm far from an expert but "these samples cluster around this rule or this 
subset of rules" is far from machine learning. There's no learning there at all.

We have used YARA to extract out features from various documents (specifically 
things like RTF where you can easily count the number of different tags, their 
relative position, etc) and then used those features to train a ML model. It 
can be done, and can work well but YARA may not be the best tool in most cases.

Just labeling a cluster based upon a set of rules that match is not machine 
learning. That is just labeling.

-- WXS

> On Jan 11, 2021, at 4:51 AM, raghvendra mishra  
> wrote:
> 
> Hi Arun,
> What about using Yara rule pattern(s) as a feature, think about it. In this 
> way you can have clusters based upon family etc.
> 
> Cheers,
> --Raghvendra Mishra
> Principal Threat Researcher
> SonicWall Inc.
> Cell:- +91-8867404241
> 
> 
> On Thu, Jan 7, 2021 at 11:28 PM arun rawat  > wrote:
> Hi Everyone,
> 
> I am a college student working on a malware detection project.
> 
> Someone told me that "Yara rules can also be used to convert a big data set 
> in the form of clusters in machine learning " and it has a different use at 
> different platforms.
> 
> I am a bit confused, Is it true or not. 
> 
> Your advice can help a student to complete his Project.
> 
> Thank you in advance.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/53e7b170-00e0-4f6d-ab1a-72c3920baa3an%40googlegroups.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACAQ8EBighB6m%2Bk_EYabwqin5fVJRgHb83L3xicZ5XXAY8eHYg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/BF164FD0-9374-4F7F-B7E6-B2983FB5094E%40gmail.com.

Re: Hopefully a simple question

[Wesley Shields]

Well, assuming you put the rules in c:\Temp\yarfile.yar, no. If you didn't put 
that file there or can't explain why it's there, then it is a positive match 
you need to investigate.

-- WXS

> On Aug 10, 2020, at 9:12 PM, Michael Fry  wrote:
> 
> So does that mean it is a positive for something being detected?
> 
> On Tuesday, 11 August 2020 10:41:48 UTC+10, Wesley Shields wrote:
> The format is  .
> 
> In your case, YARA matched two rules on the file c:\Temp\yarfile.yar
> 
> -- WXS
> 
>> On Aug 10, 2020, at 8:33 PM, Michael Fry > wrote:
>> 
>> Hi All,
>> 
>> So I have recently been asked to use Yara to scan some servers for some IOCs 
>> and I am using the command line version.
>> 
>> The yar file was provided to me.
>> 
>> I am struggling to find anything anywhere that outlines interpretting the 
>> log file. For example, if I have the below, is this indicating a type of 
>> scan using a particular yar file? Or is it indicating that it has found 
>> something?
>> 
>> webshell_embedded_jscript_evaluator c:\\Temp\yarfile.yar
>> webshell_jscript_eval c:\\Temp\yarfile.yar
>> 
>> Thanks
>> Michael
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "YARA" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to yara-p...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/yara-project/fca76a39-121e-476d-a597-9f4d3ea18cado%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/yara-project/fca76a39-121e-476d-a597-9f4d3ea18cado%40googlegroups.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> <mailto:yara-project+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/348a4407-a2b3-4d18-853d-2f7da33827dco%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/yara-project/348a4407-a2b3-4d18-853d-2f7da33827dco%40googlegroups.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/D0021161-59A1-4BDD-A7A6-F60105164DAD%40atarininja.org.

Re: Hopefully a simple question

[Wesley Shields]

The format is  .

In your case, YARA matched two rules on the file c:\Temp\yarfile.yar

-- WXS

> On Aug 10, 2020, at 8:33 PM, Michael Fry  wrote:
> 
> Hi All,
> 
> So I have recently been asked to use Yara to scan some servers for some IOCs 
> and I am using the command line version.
> 
> The yar file was provided to me.
> 
> I am struggling to find anything anywhere that outlines interpretting the log 
> file. For example, if I have the below, is this indicating a type of scan 
> using a particular yar file? Or is it indicating that it has found something?
> 
> webshell_embedded_jscript_evaluator c:\\Temp\yarfile.yar
> webshell_jscript_eval c:\\Temp\yarfile.yar
> 
> Thanks
> Michael
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/fca76a39-121e-476d-a597-9f4d3ea18cado%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/F9A47C08-C594-4FE0-AF6C-1375A23CB926%40atarininja.org.

Re: Issues - Win2K3 w/ PS Ver:2.0 + YARA 4.0.2

[Wesley Shields]

It looks like yara64 won't run because you have a 32bit install of Windows, 
that can't run 64bit binaries.

The problem with yara32 looks like it is permissions, and you don't have access 
to execute it.

Without further information this looks like it has nothing to do with YARA, and 
is a local problem.

-- WXS

> On Jul 30, 2020, at 11:33 PM, Cam Young  wrote:
> 
> Yes - these servers are on their way out (way overdue) , but we need to keep 
> them up for a few more months yet while we move websites to a 2012 stack.
> 
> Attempted to execute the yara binaries on the server this morning and was 
> returned with the following ..
> 
> C:\YARA> yara64.exe --help
> The image file C:\YARA\yara64.exe is valid, but is for a machine type other 
> than the current machine.
> 
> C:\YARA> yara32.exe --help
> Access is denied.
> 
> 
> Not sure if going backwards version wise will assist or not - and how far 
> back should I go ?
> Looking at options for this old stack.
> 
> Thanks in advance.
> 
> Cheers, Cam.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/5b17e84a-311c-4e51-bdfd-2670d89746a4o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/ADA693A0-349F-48BD-8B71-2A726D2526C0%40atarininja.org.

Re: PE rule matches when run under yara-python but not in yara ??!

[Wesley Shields]

I can't replicate this - it does not match on 4.0.2 on my system. There is no 
rule parsing bug here - the same C code is used when compiling rules using yara 
on the command line or via python. I've had a couple of people tell me 
something weird is going on when using pip to install yara-python, especially 
if you have an older install of libyara laying around. It's almost as if it 
isn't picking up the bundled version of yara and is instead falling back to 
whatever you have laying around. You commented out the printing of the version 
in your python snippet, but just to confirm that is printing the correct 
version of yara?

To be clear, I think this is a local problem and your evaluation is possibly 
incorrect. I think the bug is that it DOES match under yara-python when it 
should not. It not matching when running yara from the command line is the 
correct behavior (I think).

-- WXS

> On Jul 7, 2020, at 2:10 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi, 
> 
> This is running with the following versions on macOS 10.14.6:
> 
> yara 4.0.2 homebrew
> 
> yara-python 4.0.2 (pip) 
> Python 3.7.7
> 
> I'm having a really weird case where a rule using pe module is unexpectedly 
> matching certain files when run under yara-python , but not matching if 
> running the yara binary directly.
> 
> Running on this PE file: 
> https://www.virustotal.com/gui/file/154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8/details
>  
> 
> "test_odd_pe_py_match.yara":
> rule Odd_PE_Entry_Point
> {
> condition:
> uint16(0) == 0x5a4d and
> ((pe.entry_point >= pe.sections[pe.number_of_sections - 
> 1].raw_data_offset) or (not 
> pe.sections[pe.section_index(pe.entry_point)].name contains ".text"))
> }
> 
> 
> 
> Python :
> import yara
> #print(yara.__version__)
> 
> try:
> scan = yara.compile("./test_odd_pe_py_match.yara")
> except yara.Error as e:
> print("YARA compile error:", e)
> 
> matches = 
> scan.match(filepath="154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe")
> print(matches)
> 
> [Odd_PE_Entry_Point]
> 
> 
> yara bin:
> $ yara test_odd_pe_py_match.yara 
> 154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe
> 
> $
> No matches
> 
> 
> Can someone tell what's going on here ? 
> It seems to me there is some sort of either rule parsing bug under python, or 
> race condition that causes the python run to match when the binary doesn't.
> 
> Thanks,
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/48c4b198-182b-4f28-aecd-90db120ef1c8o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/4BA5B724-FCC0-4854-BCCD-5D06F2D150F2%40atarininja.org.

Re: Matching only fullword standalone base64 strings (ending in '==') ?

[Wesley Shields]

I don't think fullword makes sense here, given that the base64 modifiers are 
meant to work when the string you're searching for is embedded anywhere in a 
base64 encoded string. This requires that it strip some leading and trailing 
bytes. If you want to find it without this behavior just put the base64 string 
in as a literal and don't use the modifiers. A quick comment about what it is 
in decoded form will help readability.

-- WXS

> On Jul 7, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi again,
> 
> I'm wondering if there is a way to match Base64 strings only when they are 
> 'fullword', standalone.
> 
> For example:
> rule base64_Example
> {
> strings:
> $s = "setsockopt" base64 base64wide // c2V0c29ja29wdA==
> condition:
> $s
> }
> 
> 
> This rule will match anything containing the string "c2V0c29ja29wdA"
> What if I want it to only match on the standalone base64 string 
> "c2V0c29ja29wdA==" ? 
> Obviously I could match that string literal but I was curious if it would 
> make sense for base64 to do this, for readability and flexibility ? 
> 
> Using fullword with base64 modifiers does not seem to be supported.
> invalid modifier combination "base64 fullword"
> 
> Thank you, 
> 
>  - Wes
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/e160da25-1de2-4f07-bcd3-31ae0c50b779o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/393AD2E4-B029-4338-8ED6-0AC5E8BFCE15%40atarininja.org.

Re: PE module: 'not' logic conditions will match on non-PE files - should pe functions first check if file is PE ?

[Wesley Shields]

This is likely due to the change made recently where comparing with UNDEFINED 
values now evaluates to false. It used to evaluate to UNDEFINED.

> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ?

Functions in the pe module do check if they are accessing UNDEFINED fields and 
return UNDEFINED accordingly. This is the behavior of things like 
"pe.exports()" and others. In your case you have a couple of things going on...

1) You are using "pe.section_index()" which will return UNDEFINED on a non-PE 
file. This means you are accessing pe.sections[UNDEFINED] which is also 
UNDEFINED.

2) You are then accessing the name attribute of an UNDEFINED value which is 
also resulting in an UNDEFINED value.

3) You end up with 'not UNDEFINED contains ".text"' which as of a somewhat 
recent change evaluates to "not false".

This is all because of a recent change where comparisons (including contains) 
with UNDEFINED values result in false.

It's arguable that this is the right change (and to be honest, I don't remember 
why it was changed) but one thing you can do is prefix your condition with 
"pe.is_pe and ..."

-- WXS

> On Jul 1, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi,
> 
> Wanted to post here before raising an issue on github project:
> 
> To reproduce:
> import "pe"
> 
> rule pe_on_nonpe
> {
> condition:
>   not pe.sections[pe.section_index(pe.entry_point)].name contains ".text"
> }
> 
> 
> 
> Run on non-PE file (e.g. Excel document zip)
> yara pe_on_nonpe.yara excel_doc.xlsx
> The rule matches on non-PE files
> 
> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ? 
> So pe.sections implies the file is PE, does check for valid PE first 
> 
> Regards,
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/558ba95d-4f7c-4bd7-a8bb-71fab8c97db0o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/8BDBC9BC-BC20-43F3-86E7-2915154EB077%40atarininja.org.

Re: Match On Export Directory Name

[Wesley Shields]

OK, that makes a bit more sense. I see what you want to do now, and there is no 
easy way to do it that I'm aware of, but there is a rather cumbersome way to do 
it.

import "pe"

rule a {
  strings:
$pilot = "pilot.dll"
  condition:
$pilot at 
pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address)
 + 12))
}

This will check if pilot.dll is in the appropriate spot.

We currently don't expose that field in the pe module. I am working on some 
improvements to export and import parsing and can probably include this in 
there too, but no promises if it will be accepted. :)

-- WXS

> On Jun 27, 2019, at 10:20 AM, Schrodinger  wrote:
> 
> Sorry for the confusion, I think I worded things incorrectly in my original 
> post. The Export Table name, not an exported function.
> 
> https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#export-directory-table
> 
> In the Export Table there is the name of the module itself. "The address of 
> the ASCII string that contains the name of the DLL. This address is relative 
> to the image base." I'd like to use Yara to find samples with the same Export 
> name, not the name of an exported function.
> 
> Cheers,
> Schrodinger.
> 
> On Thursday, June 27, 2019 at 12:40:03 AM UTC+1, Wesley Shields wrote:
> Not sure where you got "pilot.dll" from but the file you referenced has one 
> export by name and that is MSOProtect. 
> 
> -- WXS 
> 
> > On Jun 26, 2019, at 7:04 PM, Schrodinger  wrote: 
> > 
> > Doesn't seem to work for me. Just trying a simple rule. 
> > 
> > import "pe" 
> > 
> > rule export_name 
> > { 
> > condition: 
> > uint16(0) == 0x5A4D 
> > and 
> > pe.exports("pilot.dll") 
> > } 
> > 
> > Sample I tested with d5c679df69751936d0fa380f2e4bf017 can provide the 
> > sample if you need. 
> > 
> > Cheers. 
> > 
> > On Wednesday, June 26, 2019 at 2:00:47 AM UTC+1, Wesley Shields wrote: 
> > For now you can do: pe.exports("pilot.dll"). 
> > 
> > -- WXS 
> > 
> > > On Jun 25, 2019, at 6:21 PM, Schrodinger  wrote: 
> > > 
> > > Hi everyone, 
> > > 
> > > I was wondering if there is a way to perform matching on the name in the 
> > > DIRECTORY_ENTRY_EXPORT in a Portable Executable. Example from the Python 
> > > pefile module: 
> > > 
> > > In [32]: pe.DIRECTORY_ENTRY_EXPORT.name 
> > > Out[32]: 'pilot.dll' 
> > > 
> > > Cheers, 
> > > Schrodinger. 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google Groups 
> > > "YARA" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to yara-p...@googlegroups.com. 
> > > To view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/yara-project/2f7a4837-7ce7-430f-a826-0bde055170af%40googlegroups.com.
> > >  
> > > For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "YARA" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to yara-p...@googlegroups.com. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/yara-project/0ddcbcce-328e-4535-8e3f-f90b61616cd0%40googlegroups.com.
> >  
> > For more options, visit https://groups.google.com/d/optout. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/7cb565f6-b437-4f3e-9224-f928c7538b71%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/CE737C4A-C8BD-4EFC-9679-40F1639B447A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Match On Export Directory Name

[Wesley Shields]

Not sure where you got "pilot.dll" from but the file you referenced has one 
export by name and that is MSOProtect.

-- WXS

> On Jun 26, 2019, at 7:04 PM, Schrodinger  wrote:
> 
> Doesn't seem to work for me. Just trying a simple rule.
> 
> import "pe"
> 
> rule export_name
> {
> condition:
> uint16(0) == 0x5A4D
> and
> pe.exports("pilot.dll")
> }
> 
> Sample I tested with d5c679df69751936d0fa380f2e4bf017 can provide the sample 
> if you need.
> 
> Cheers.
> 
> On Wednesday, June 26, 2019 at 2:00:47 AM UTC+1, Wesley Shields wrote:
> For now you can do: pe.exports("pilot.dll"). 
> 
> -- WXS 
> 
> > On Jun 25, 2019, at 6:21 PM, Schrodinger  wrote: 
> > 
> > Hi everyone, 
> > 
> > I was wondering if there is a way to perform matching on the name in the 
> > DIRECTORY_ENTRY_EXPORT in a Portable Executable. Example from the Python 
> > pefile module: 
> > 
> > In [32]: pe.DIRECTORY_ENTRY_EXPORT.name 
> > Out[32]: 'pilot.dll' 
> > 
> > Cheers, 
> > Schrodinger. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "YARA" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to yara-p...@googlegroups.com. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/yara-project/2f7a4837-7ce7-430f-a826-0bde055170af%40googlegroups.com.
> >  
> > For more options, visit https://groups.google.com/d/optout. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/0ddcbcce-328e-4535-8e3f-f90b61616cd0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/D396795E-598D-4087-9117-33CB2B670390%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Match On Export Directory Name

[Wesley Shields]

For now you can do: pe.exports("pilot.dll").

-- WXS

> On Jun 25, 2019, at 6:21 PM, Schrodinger  wrote:
> 
> Hi everyone,
> 
> I was wondering if there is a way to perform matching on the name in the 
> DIRECTORY_ENTRY_EXPORT in a Portable Executable. Example from the Python 
> pefile module:
> 
> In [32]: pe.DIRECTORY_ENTRY_EXPORT.name
> Out[32]: 'pilot.dll'
> 
> Cheers,
> Schrodinger.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/2f7a4837-7ce7-430f-a826-0bde055170af%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/D1A20454-76EF-4928-9CD7-9B8DC8A220FB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara configure statically with modules

[Wesley Shields]

What about:

./configure --enable-static --enable-cuckoo --enable-magic --enable-dotnet

-- WXS

> On May 3, 2019, at 5:22 AM, Shakarim Utepbergenov 
>  wrote:
> 
> Hello guys, I need to build a executable binary file on Ubuntu 18.04
> i've tried configure with static libs
> ./configure --enable-cuckoo --enable-magic --enable-dotnet LDFLAGS="-static" 
> and has some errors;
> Does anyone have experience in build statics?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: YARA rule to search for a file with a certain name

[Wesley Shields]

Filename is not something YARA knows about, nor should it IMO. The filename is 
a property of the filesystem upon which the file resides, and has no bearing on 
the content of the file. If you want to use filename in your rule you have to 
pass it in as an external variable. Check out 
https://github.com/VirusTotal/yara/issues/202 for more details.

-- WXS

> On Nov 12, 2018, at 7:21 AM, Michael Herren  wrote:
> 
> Hello
> 
> Please be gentle with me. I am new to YARA and the writting of such rules. I 
> am planning to write a set of YARA rules each describing an IOC. A very 
> simple IOC is the existence of a certain file. I was search the net for a 
> rule which check if a file with a certain name does exist. But all examples I 
> found do not work on my computer. This could be based on my lack of knowledge 
> or the fact that such a function is not existing.
> 
> Can anyone please help?
> 
> Kind Regards
> Michael
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: './configure --dotnet' doesn't work - 'import dotnet' returns error

[Wesley Shields]

It should be —enable-dotnet

— WXS

On Wed, Nov 7, 2018 at 2:09 PM  wrote:

>
> Newbie question - The instructions to get .net rules appear to be
> straight-forward, but it doesn't appear to be working.
>
>
> I've followed the install and configure instructions:
>
> ./bootstrap.sh
> ./configure --dotnet
> make
> make install
>
> ar -t /usr/local/lib/libyara.a shows dotnet.o in libyara.a
>
> However, when I'm trying to compile a rule in a file that just has "import
> dotnet" at the top. I get compiler error no 34, which I believe is "
> ERROR_UNKNOWN_MODULE".
>
>   compiler->last error is 34
>   compiler->last_error_extra_info is do
>   compiler->last_error_line is 1  [the line that says "import dotnet"]
>
> Code is
>
> 
> int  main(int argc, char **argv) {
>
>   int result = 0;
>
>   /* Initialize libyara */
>   result = yr_initialize(); /* returns int */
>   printf("initialize result: %d\n",result);
>
>   /* Create new compiler instance. */
>   result = yr_compiler_create(_ctx);
>   printf("compiler instance: %d\n",result);
>
>   /* Load rule file, and compile it. */
>   FILE *rule = fopen(YARA_CHAT_RULE, "r");
>   result = yr_compiler_add_file(comp_ctx, rule, NULL, YARA_CHAT_RULE);
>   printf("compile error on entry : error no.: %d\n",comp_ctx->last_error);
>   printf("compile error on entry : error info:
> %s\n",comp_ctx->last_error_extra_info);
>   printf("compile error on entry : error line:
> %d\n",comp_ctx->last_error_line);
>   printf("no. compile errors: %d\n", result);
>
>  
>
> Creating the compiler returns 0
>
> Any reason why I can't get the dotnet module to be recognized?
> I'm on Centos Linux version 3.10.0-862.14.4.el7.x86_64 (gcc version 4.8.5
> 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Wed Sep 26 15:12:11 UTC 2018
> Yara version is 3.8.1
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: error: syntax error, unexpected '=', expecting _STRING_IDENTIFIER_

[Wesley Shields]

The inner quotes are not escaped.

— WXS

On Sun, Mar 18, 2018 at 8:24 PM  wrote:

> Hi
>
> I ran this rule while learning:
> echo "rule a { strings: $h = "arnav" condition: $h } > a
>
> but when I run
> yara a a
>
> it gives me this error:
> error: syntax error, unexpected '=', expecting _STRING_IDENTIFIER_
>
> I can't figure out what's wrong.
>
> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using module_callback more than once

[Wesley Shields]

This should show you what is going on:

>>> f = open('/bin/ls')
>>> data = f.read()
>>> f.close()
>>> import yara
>>> rules = yara.compile(source='import "pe" rule a { condition: false }')
>>> def foo(data):
... global resources
... resources = data.get('number_of_resources')
...
>>> resources = 0
>>> rules.match(data=data, modules_callback=foo)
[]
>>> print resources
None
>>> f = open('/Users/wxs/malware/test.exe')
>>> data = f.read()
>>> f.close()
>>> rules.match(data=data, modules_callback=foo)
[]
>>> print resources
23
>>>

When I feed it a file that is not a PE file the number_of_resources key in the 
data dictionary doesn't exist so attempting to call .get() on it returns None.

-- WXS

> On Mar 13, 2018, at 4:00 PM, Matan Bachar  wrote:
> 
>  Hello everyone
> I am doing a yara-python project and Im using this technique to getting 
> information about PE files:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> My problem is when im using more than one time with this technique and its 
> not working. Its just return 'None' instead of the value it should return
> Every time Im use this technique only one time its working no matter what...
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting information about PE using yara-python

[Wesley Shields]

Sure, I've been using it to unpack and handle config blocks from .NET binaries 
using this technique:

https://gist.github.com/wxsBSD/1e518cef545fee7bb991a9dc6c14a0f7

Substitute the dotnet module for the pe module and you will get access to all 
the information exposed via the PE module (you won't get things that require 
function calls like imports and exports though).

-- WXS

> On Mar 12, 2018, at 12:49 PM, Matan Bachar  wrote:
> 
> Is there a way to get information about PE file using yara-python command 
> directly or indirectly? (section number,timestamp etc)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara-python and Warning for RegEx Resonable Value for N

[Wesley Shields]

You will need to provide an example. Please include the rule and exact commands 
and outputs you're getting when running things. Also, please include versions 
of things you're using.

-- WXS

> On Feb 23, 2018, at 9:47 AM, Binaries 4 Breakfast 
>  wrote:
> 
> Sorry, this was Yarac, but perhaps also with Yara-python.
> 
> On Friday, February 23, 2018 at 8:45:31 AM UTC-6, Binaries 4 Breakfast wrote:
> Folks, I recently found that a yara-python rule compilation will hang when 
> returning the Warning regarding a regex for a reasonable value of N, but not 
> in stand-alone Yara. Is this a bug?
> 
> -JD
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara-python and Warning for RegEx Resonable Value for N

[Wesley Shields]

Can you share the rule and the version of YARA you're using? If true it is a 
bug but I suspect it isn't true. I think you may have a local problem.

-- WXS

> On Feb 23, 2018, at 9:45 AM, Binaries 4 Breakfast 
>  wrote:
> 
> Folks, I recently found that a yara-python rule compilation will hang when 
> returning the Warning regarding a regex for a reasonable value of N, but not 
> in stand-alone Yara. Is this a bug?
> 
> -JD
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: problem compiling yara rules downloaded from yara-rules repository also doing this in Python2.7 using yara-python

[Wesley Shields]

The first one is because you don't have the androguard module compiled. The 
second one is because you don't have the cuckoo module compiled. The androguard 
requirement, which isn't part of YARA (yet?), is documented in their README. 
The cuckoo module can be enabled with ./configure --enable-cuckoo and 
rebuilding YARA.

-- WXS

> On Feb 4, 2018, at 3:57 PM, Yash Patel  wrote:
> 
> these are the errors I'm getting
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Also, How are you doing? THANK YOU! :-) 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Are raw files necessary for Yara? Can the outputs of "strings" be fed to the yara processor?

[Wesley Shields]

You could do that. You would lose any capabilities based upon most of the 
modules (PE, elf, etc). The math module would still work but I'm not sure how 
relevant it would be. More importantly I'm not sure what doing this would get 
you that running YARA on the original files wouldn't also get you, with none of 
the loss of capabilities.

-- WXS

> On Nov 14, 2017, at 7:09 PM, plagu...@gmail.com wrote:
> 
> I understand that some tweaking might be necessary to the yara processor, but 
> I am wondering if something like this would be possbile.
> 
> If in the past I had stored the "strings" output of a particular file, could 
> I pump that into a modified yara processor and have everything work? Are 
> there some things that wouldn't work?
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara not using global rules

[Wesley Shields]

Ok, so it isn’t a question of incorrect matching like you originally said.
It is really a question of searching a file even if it doesn’t pass the
global rules. This is a misunderstanding I sometimes see. All strings are
collected and searched for in a single pass, then global rules are
evaluated.

— WXS

On Thu, Aug 17, 2017 at 6:49 AM necrophcodr <tcg.thega...@gmail.com> wrote:

> Alright, I've solved the issue:
>
> Albeit this is synthetic, running
>
> ```
> for f in $(seq 0 100); do printf "\n\n\n\n\n\n\n\n\n\n" >> text.txt;
> done
> ```
>
> And then
>
> ```
> yara inc.yar .
> ```
>
> In the directory with the yara files, yields, on my test system:
>
> ./misc.yar(9): warning: $newline is slowing down scanning (critical!)
> fsL ./inc.yar
> fsL ./global.yar
> fsL ./misc.yar
> error scanning ./text.txt: internal error: 30
>
>
> And while using the newline scan is not a great idea, clearly the file is
> still being scanned in one way or another, in spite of the global rule.
>
>
> Den torsdag den 17. august 2017 kl. 12.24.11 UTC+2 skrev necrophcodr:
>>
>> I'm afraid I cannot post the exact files. I'll create a working
>> environment that replicates all the variables required, and I'll post it
>> here when I've gotten this done.
>>
>> Den onsdag den 16. august 2017 kl. 16.31.35 UTC+2 skrev Wesley Shields:
>>>
>>> I still can not replicate your problem.
>>>
>>> A couple of things to note however:
>>>
>>> "internal error: 30" is because there are too many matches, which
>>> happens when a single string matches too many times. It has nothing to do
>>> with file size like you guessed.
>>>
>>> Your "newline_one" rule is marked as private so it should never be
>>> reported.
>>>
>>> At this point I can not replicate your problem so I'm curious if you
>>> could zip up the files you're using to do this and post them somewhere for
>>> me to see them exactly? I would need your exact YARA rules and the file you
>>> are scanning.
>>>
>>> -- WXS
>>>
>>> > On Aug 16, 2017, at 5:51 AM, necrophcodr <tcg.th...@gmail.com> wrote:
>>> >
>>> > Alright, so I've returned with a result:
>>> >
>>> > If I have `~/inc.yar` with the following content:
>>> >
>>> > ```
>>> > include "./global.yar"
>>> > include "./misc.yar"
>>> > ```
>>> >
>>> > And the content of these files respectively:
>>> >
>>> > ```
>>> > global rule fsL { condition: filesize < 8MB }
>>> > ```
>>> >
>>> > And
>>> >
>>> > ```
>>> > private rule newline_one {
>>> > meta:
>>> > description = "Files that contain one newline"
>>> > author = "Steffen Rytter Postas"
>>> >
>>> > strings:
>>> > $newline = "\n"
>>> >
>>> > condition:
>>> > ( #newline == 1 )
>>> > }
>>> > ```
>>> >
>>> > Then the issue prevails.
>>> >
>>> > Note that this requires an actually large file that contains newlines.
>>> Doing `dd if=/dev/zero bs=4M count=250 of=file.bin` and scanning that won't
>>> yield usable results.
>>> >
>>> > Den onsdag den 16. august 2017 kl. 11.43.17 UTC+2 skrev necrophcodr:
>>> > Hi Wesley,
>>> >
>>> > Sorry for the late reply, vacations and all.
>>> >
>>> > So first and foremost:
>>> >
>>> > `yara -v`
>>> > yara 3.5.0
>>> >
>>> > The files getting scanned are reporting ` internal error: 30` which
>>> I'm reading to be due to files being too large. These files are often
>>> larger than 500MB too, well above the 8MB margin.
>>> >
>>> > I've attempted to replicate it using my own instructions, coupled with
>>> your misc.yar, and the result is that it works just fine.
>>> >
>>> > So I'm guessing the issue is with my own setup, and I'll continue
>>> evaluating the specifics and return with a response when I've found the
>>> culprit.
>>> >
>>> > Den mandag den 7. august 2017 kl. 16.06.59 UTC+2 skrev Wesley Shields:
>>> > I can't replicate this behavior using 3.5.0 or latest master.
>>

Re: Yara not using global rules

[Wesley Shields]

I still can not replicate your problem.

A couple of things to note however:

"internal error: 30" is because there are too many matches, which happens when 
a single string matches too many times. It has nothing to do with file size 
like you guessed.

Your "newline_one" rule is marked as private so it should never be reported.

At this point I can not replicate your problem so I'm curious if you could zip 
up the files you're using to do this and post them somewhere for me to see them 
exactly? I would need your exact YARA rules and the file you are scanning.

-- WXS

> On Aug 16, 2017, at 5:51 AM, necrophcodr <tcg.thega...@gmail.com> wrote:
> 
> Alright, so I've returned with a result:
> 
> If I have `~/inc.yar` with the following content:
> 
> ```
> include "./global.yar"
> include "./misc.yar"
> ```
> 
> And the content of these files respectively:
> 
> ```
> global rule fsL { condition: filesize < 8MB }
> ```
> 
> And
> 
> ```
> private rule newline_one {
> meta:
> description = "Files that contain one newline"
> author = "Steffen Rytter Postas"
> 
> strings:
> $newline = "\n"
> 
> condition:
> ( #newline == 1 )
> }
> ```
> 
> Then the issue prevails.
> 
> Note that this requires an actually large file that contains newlines. Doing 
> `dd if=/dev/zero bs=4M count=250 of=file.bin` and scanning that won't yield 
> usable results.
> 
> Den onsdag den 16. august 2017 kl. 11.43.17 UTC+2 skrev necrophcodr:
> Hi Wesley,
> 
> Sorry for the late reply, vacations and all.
> 
> So first and foremost: 
> 
> `yara -v`
> yara 3.5.0
> 
> The files getting scanned are reporting ` internal error: 30` which I'm 
> reading to be due to files being too large. These files are often larger than 
> 500MB too, well above the 8MB margin.
> 
> I've attempted to replicate it using my own instructions, coupled with your 
> misc.yar, and the result is that it works just fine.
> 
> So I'm guessing the issue is with my own setup, and I'll continue evaluating 
> the specifics and return with a response when I've found the culprit.
> 
> Den mandag den 7. august 2017 kl. 16.06.59 UTC+2 skrev Wesley Shields:
> I can't replicate this behavior using 3.5.0 or latest master. 
> 
> wxs@wxs-mbp yara % cat foo 
> include "./global.yar" 
> include "./misc.yar" 
> wxs@wxs-mbp yara % cat global.yar 
> global rule fileSizeLimit { condition: filesize < 1KB } 
> wxs@wxs-mbp yara % cat misc.yar 
> rule foo { condition: true } 
> wxs@wxs-mbp yara % ls -l /bin/ls 
> -rwxr-xr-x  1 root  wheel  38624 Jul 15 00:29 /bin/ls* 
> wxs@wxs-mbp yara % ./yara foo /bin/ls 
> wxs@wxs-mbp yara % 
> 
> When you say regardless of file size are you sure you're above the 8MB? Keep 
> in mind that 8MB is 8 * 1048576, which is 8388608. 
> 
> -- WXS 
> 
> > On Jul 28, 2017, at 7:01 AM, necrophcodr <tcg.th...@gmail.com> wrote: 
> > 
> > So I've got quite a few rules, but it all comes down to this: 
> > 
> > include "./rules/global.yar" 
> > include "./rules/misc.yar" 
> > 
> > 
> > The global.yar file contains 
> > 
> > global rule fileSizeLimit { condition: filesize < 8MB } 
> > 
> > 
> > Any rule defined in rules/misc.yar are matched regardless of file size, but 
> > this is not what I intend. What am I doing wrong here? 
> > 
> > If this is not the right place to post, that's alright, feel free to slap 
> > me on the wrist and direct me to the correct location. 
> > 
> > edit: 
> > 
> > I should mention this is using Yara 3.5.0. I don't have a chance to upgrade 
> > this within the week. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "YARA" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to yara-project...@googlegroups.com. 
> > For more options, visit https://groups.google.com/d/optout. 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara not using global rules

[Wesley Shields]

I can't replicate this behavior using 3.5.0 or latest master.

wxs@wxs-mbp yara % cat foo
include "./global.yar"
include "./misc.yar"
wxs@wxs-mbp yara % cat global.yar
global rule fileSizeLimit { condition: filesize < 1KB }
wxs@wxs-mbp yara % cat misc.yar
rule foo { condition: true }
wxs@wxs-mbp yara % ls -l /bin/ls
-rwxr-xr-x  1 root  wheel  38624 Jul 15 00:29 /bin/ls*
wxs@wxs-mbp yara % ./yara foo /bin/ls
wxs@wxs-mbp yara %

When you say regardless of file size are you sure you're above the 8MB? Keep in 
mind that 8MB is 8 * 1048576, which is 8388608.

-- WXS

> On Jul 28, 2017, at 7:01 AM, necrophcodr  wrote:
> 
> So I've got quite a few rules, but it all comes down to this:
> 
> include "./rules/global.yar"
> include "./rules/misc.yar" 
> 
> 
> The global.yar file contains
> 
> global rule fileSizeLimit { condition: filesize < 8MB }
> 
> 
> Any rule defined in rules/misc.yar are matched regardless of file size, but 
> this is not what I intend. What am I doing wrong here?
> 
> If this is not the right place to post, that's alright, feel free to slap me 
> on the wrist and direct me to the correct location.
> 
> edit:
> 
> I should mention this is using Yara 3.5.0. I don't have a chance to upgrade 
> this within the week.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: yara python callback function , slow performance

[Wesley Shields]

Based upon my understanding I don't think this is expected behavior. Can you 
share a minimal proof of concept which shows this happening?

-- WXS

> On May 17, 2017, at 8:18 AM, tofbaas...@gmail.com wrote:
> 
> Hello again , 
> 
> I'm using yara python to match rules against a lot of files . The problem is 
> when the number of files gets big the performance is really horrible . 
> 
> When doing some profiling I noticed that when running 12319 files against 
> about a 1000 to 1500 rules the yara callback function gets called 151991822 
> times ?
> Does the callback function get called for each matching string of a rule ? 
> In my test I only had 28 matches so it's not that I'm doing any heavy lifting 
> if there's a match
> Is there anything I can do about this , or is this behaviour to be expected 
> with this number of files ? I haven't compared against native yara yet ...
> 
> Thank you
> 
> 
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: determining which strings causes a rule to fail

[Wesley Shields]

What about this:

wxs@wxs-mbp yara % cat foo
foo
wxs@wxs-mbp yara % cat bar
rule test {
  strings:
$a = "foo"
$b = "bar"
  condition:
all of them
}
wxs@wxs-mbp yara % ./yara -ns bar foo
test foo
0x0:$a: foo
wxs@wxs-mbp yara %

This prints all rules that DO NOT match and the strings in them that DO match 
(and by process of elimination the strings that DO NOT match are the ones left 
over). Keep in mind though that strings are not the only things that can cause 
a condition to evaluate to false.

-- WXS

> On Nov 17, 2016, at 10:03 AM, John Davison  wrote:
> 
> Hey there,
> 
> We often run other peoples rules, and at times when we scan larger files we 
> get "internal error: 30" which indicates that yara matched too many strings 
> and basically ran out of room.
> 
> The question that naturally follows is "which string in which rule caused the 
> problem?"  That's hard to figure out because the files we load often have 
> dozens of rules with lots of strings.
> 
> It would be helpful if there was an option that listed the top N strings in 
> order of how many times they matched (and what rule they're in), in 
> descending order.
> 
> Does this functionality exist in other ways?  If not, then could someone 
> point me in what areas of the source code I need to look at to accomplish 
> this?  Would anyone else find this useful?
> 
> -- 
> John W. Davison
> unixfreak0...@gmail.com
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara needs overlay offset

[Wesley Shields]

I haven't looked at the code, but there is precedent to use pe.overlay.offset 
and pe.overlay.size.

-- WXS

> On Aug 15, 2016, at 12:02 AM, Fernando Mercês  wrote:
> 
> Sorry to reply to an old thread but I had the same need and decided to create 
> a patch (discussion at https://github.com/VirusTotal/yara/issues/432), that 
> is on my Yara fork at https://github.com/merces/yara/
> 
> This commit adds pe.overlay location: 
> https://github.com/merces/yara/commit/39447516d82454f46988fac7313aebe8ce356f88
> This one adds the pe.overlay_size integer: 
> https://github.com/merces/yara/commit/089e8915c1cde8274ab729789a1edc9cc2235b0c
> 
> So rules like these would work:
> 
> rule overlay_bytes {
>   strings:
>   $bytes = { 41 42 43 44 45 }
>   condition:
>   $bytes at pe.overlay
> }
> 
> rule has_overlay {
>   condition:
>   pe.overlay
> }
> 
> rule big_overlay {
>   condition:
>   pe.overlay_size > 10
> }
> 
> 
> @Victor, do you believe the patch is good enough for a pull request?
> 
> Att,
> 
> @MercesFernando
> mentebinaria.com.br
> ---
> 
> On Wed, Dec 2, 2015 at 7:46 AM, Víctor Manuel Álvarez García 
>  wrote:
> Sure, i think this makes a lot of sense. Thank you for the suggestion.
> 
> On Tue, Dec 1, 2015 at 10:05 PM, Glenn J  wrote:
> rule SkDUndetectabler : SkDrat {
> meta:
> author = "me"
> condition:
> (
> borland_delphi or //check All FSG or
> ((pe.linker_version.major == 6) and (pe.linker_version.minor == 0 ))
> )
> and
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  < filesize) and
> //is overlay at offset 2A00,1A00,C00,745,739
> //pe.overlay & pe.overlay_size would have been prettier
> ( 
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  == 0x0739)  or
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  == 0x0745)  or
> //Uncompressed
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  == 0x0C00)  or
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  == 0x2A00)  or
> 
> (pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size
>  == 0x1A00)
> )
> and
> //is xored MZ ?
> ( 
> 
> uint16(pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size)
>  == 0x6275 or
> 
> uint16(pe.sections[pe.number_of_sections-1].raw_data_offset+pe.sections[pe.number_of_sections-1].raw_data_size)
>  == 0x4057
> )
> }
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How about importing yara into kernel space ?

[Wesley Shields]

If you are infected with a rootkit moving YARA into the kernel is not an answer 
since the rootkit has full access to muck around with YARA even if it is in the 
kernel.

My recommendation is don't run YARA on a system which is potentially 
compromised with a rootkit like you describe. If the kernel of the system is 
compromised you can no longer trust it.

Sure, it's possible to put YARA in the kernel but it isn't going to get you 
anything if your concern is rootkits.

-- WXS

> On Mar 18, 2016, at 1:19 AM, 慎增刘  wrote:
> 
> Yara is so powerful in malware matching. Sometimes people want to check files 
>  , which attached to file-systems hooks. So how about importing yara ( or 
> just libyara ) into linux kernel?  Is it possible? Is there some advices?  
> Thanks for each response.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How about importing yara into kernel space ?

[Wesley Shields]

Not entirely true. The YARA VM does not run native instructions directly, so if 
you did manage to jump somewhere other than YARA instructions the VM would 
likely crash badly. If this can lead to arbitrary code execution, I have no 
idea.

Jumps are not bad. BPF, which runs in the kernel, allows forward jumps. 
Backward jumps are not allowed because it could cause an infinite loop. As long 
as you ensure that your jumps are within the bounds of the YARA bytecode then 
they are perfectly fine.

-- WXS

> On Mar 18, 2016, at 11:33 AM, Shiv M <shivakumar.melmanga...@gmail.com> wrote:
> 
> Yara rules with jump constructs would make it easy to get code execution in 
> the kernel.
> 
> On Fri, Mar 18, 2016 at 6:03 AM Wesley Shields <wshie...@gmail.com> wrote:
> If you are infected with a rootkit moving YARA into the kernel is not an 
> answer since the rootkit has full access to muck around with YARA even if it 
> is in the kernel.
> 
> My recommendation is don't run YARA on a system which is potentially 
> compromised with a rootkit like you describe. If the kernel of the system is 
> compromised you can no longer trust it.
> 
> Sure, it's possible to put YARA in the kernel but it isn't going to get you 
> anything if your concern is rootkits.
> 
> -- WXS
> 
> > On Mar 18, 2016, at 1:19 AM, 慎增刘 <shenzeng@gmail.com> wrote:
> >
> > Yara is so powerful in malware matching. Sometimes people want to check 
> > files  , which attached to file-systems hooks. So how about importing yara 
> > ( or just libyara ) into linux kernel?  Is it possible? Is there some 
> > advices?  Thanks for each response.
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "YARA" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to yara-project+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Yara - Bus error: 10

[Wesley Shields]

What happens if you move the crashing folders off CIF and onto local disk? If 
it still crashes can you narrow it down to a single file and rule (or set of 
rules) that crash? If you can do that then I can try to replicate and debug 
from there.

-- WXS

> On Mar 1, 2016, at 6:19 PM, Patrick Olsen  wrote:
> 
> I have a Mac with a mounted CIF share and I am attempting to recursively scan 
> the share with yara and I am getting a, "Bus error: 10" error.  A bit of 
> searching points to a string handling error.  Has anyone ran into this issue 
> before?  I have never run into this error before in the past.  It works on 
> some folders, but dies on others.
> 
> $yara -v
> yara 3.4.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [yara-python] How to get the rule name of every compiled rule?

[Wesley Shields]

I don't recall exactly when it was added but probably is in newer versions
than what you have.

-- WXS

On Friday, March 4, 2016, Robert Giczewski <robert.giczew...@gmail.com>
wrote:

> yara 3.2.0
> yara-python 2.0
>
> Am Freitag, 4. März 2016 14:35:21 UTC+1 schrieb Wesley Shields:
>>
>> What version of YARA are you using? That should work but I'm unable to
>> confirm right now.
>>
>> -- WXS
>>
>> On Friday, March 4, 2016, Robert Giczewski <robert.g...@gmail.com> wrote:
>>
>>> That would be too easy ;-)
>>>
>>> TypeError: 'yara.Rules' object is not iterable
>>>
>>>
>>> Am Freitag, 4. März 2016 13:59:11 UTC+1 schrieb Wesley Shields:
>>>>
>>>> I believe there is support for this that was added a while back.
>>>> Totally untested but I believe it goes like this:
>>>>
>>>> for rule in rules:
>>>> print rule.identifier
>>>>
>>>> -- WXS
>>>>
>>>> On Friday, March 4, 2016, Robert Giczewski <robert.g...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I'm currently loading quite a lot of files containing even more yara
>>>>> rules.
>>>>> After loading the files, I'm compiling the rules so I can check files
>>>>> against the rules. (see the code below)
>>>>>
>>>>> print "[*] Loading rules (%s) ... " % (rules_dir)
>>>>>
>>>>> sigs = dict([(name.replace(".yara", "").split("/")[-1], name) for name
>>>>> in glob.glob(rules_dir + "/*.yara")])
>>>>> rules = yara.compile(filepaths=sigs)
>>>>>
>>>>>
>>>>> Before checking any file, I want to see the names of every rule I
>>>>> successfully compiled.
>>>>> I'd love to have something like:
>>>>>
>>>>>
>>>>> for rule in rules.getNames():
>>>>> print rule
>>>>>
>>>>> # badAss-1-rule
>>>>> # badAss-2-rule
>>>>> # ...
>>>>> # badAss-n-rule
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rob
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "YARA" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to yara-project+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "YARA" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to yara-project+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','yara-project%2bunsubscr...@googlegroups.com');>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [yara-python] How to get the rule name of every compiled rule?

[Wesley Shields]

What version of YARA are you using? That should work but I'm unable to
confirm right now.

-- WXS

On Friday, March 4, 2016, Robert Giczewski <robert.giczew...@gmail.com>
wrote:

> That would be too easy ;-)
>
> TypeError: 'yara.Rules' object is not iterable
>
>
> Am Freitag, 4. März 2016 13:59:11 UTC+1 schrieb Wesley Shields:
>>
>> I believe there is support for this that was added a while back. Totally
>> untested but I believe it goes like this:
>>
>> for rule in rules:
>> print rule.identifier
>>
>> -- WXS
>>
>> On Friday, March 4, 2016, Robert Giczewski <robert.g...@gmail.com> wrote:
>>
>>> Hi,
>>> I'm currently loading quite a lot of files containing even more yara
>>> rules.
>>> After loading the files, I'm compiling the rules so I can check files
>>> against the rules. (see the code below)
>>>
>>> print "[*] Loading rules (%s) ... " % (rules_dir)
>>>
>>> sigs = dict([(name.replace(".yara", "").split("/")[-1], name) for name
>>> in glob.glob(rules_dir + "/*.yara")])
>>> rules = yara.compile(filepaths=sigs)
>>>
>>>
>>> Before checking any file, I want to see the names of every rule I
>>> successfully compiled.
>>> I'd love to have something like:
>>>
>>>
>>> for rule in rules.getNames():
>>> print rule
>>>
>>> # badAss-1-rule
>>> # badAss-2-rule
>>> # ...
>>> # badAss-n-rule
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>>
>>> Rob
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "YARA" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to yara-project+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to yara-project+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','yara-project%2bunsubscr...@googlegroups.com');>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No yara-python after make installing

[Wesley Shields]

I think the documentation applies to the most recent release, and it looks like 
you may be using the latest master. If that is the case, the yara-python code 
now lives in a separate repository.

-- WXS

> On Feb 11, 2016, at 10:26 AM, Geoffrey Van Den Berge 
>  wrote:
> 
> Hello,
> 
> It says in the documentation that after the install of yara, you can cd into 
> yara-python and then run the python build and install.
> However, I don't have a yara-python folder. Do I have explicitly install the 
> python extension or am I missing something?
> In this dockerfile the user did the same thing as I am trying to do.
> 
> Thanks in advance
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ports Secteam

[Wesley Shields]

As I've been unable to contribute to this team or to ports much lately I hereby 
request that I be removed from this team. I'd rather someone else who is more 
actively engaged take my spot.

-- WXS

 On Jun 8, 2015, at 7:31 PM, Xin Li delp...@delphij.net wrote:
 
 Signed PGP part
 On 06/08/15 14:37, Robert Simmons wrote:
  I'm sure that the reason these questions have not been answered is
  simply because they may have gotten lost in the volume of traffic
  on freebsd-ports. In the following thread, there are a number of
  folks with enough passion to volunteer time to help with the Ports
  Secteam, but we're having difficulty getting a few basic questions
  answered.
  https://lists.freebsd.org/pipermail/freebsd-ports/2015-May/099268.html
 
   Here are the basic questions:
 
  Who are the members of the Ports Secteam?
 
 Current members include the current security officers (who act as a
 fallback when needed and a contact for liaison for sensitive and
 embargoed information) and:
 
 Eitan Adler (eadler@);
 Jason Helfman (jgh@);
 Martin Wilke (miwi@);
 Eygene Ryabinkin (rea@);
 Sofian Brabez (sbz@);
 Simon L. B. Nielsen (simon@, clusteradm@ liaison);
 Steve Wills (swills@);
 Wesley Shields (wxs@);
 Ryan Steinmetz (zi@);
 
  How does one join the Ports Secteam?
 
 Per previous discussion with portmgr@, members are volunteers selected
 by the Security Officer from active ports committers who have made
 commits in the ports tree in the last 90 days.
 
 Cheers,
 --
 Xin LI delp...@delphij.nethttps://www.delphij.net/
 FreeBSD - The Power to Serve!   Live free or die
 
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [tcpdump-workers] [tcpdump] New feature to limit capture file size (#464)

[Wesley Shields]

 On Jun 10, 2015, at 7:35 AM, Darren Reed darr...@netbsd.org wrote:
 
 On 10/06/2015 5:42 AM, Michael Richardson wrote:
 re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes:
 We have the -C option, giving a file size in megabytes (real megabytes, 
 i.e. 1,000,000 bytes, not 1,048,576 bytes); once the file gets that big, 
 tcpdump switches to a new file. This adds another file size option, with a 
 different syntax for the size option, and with tcpdump stopping rather than 
 rotating files when it reaches that size. We also have the -G option, to 
 rotate files based on time rather than size. We might want to consider 
 cleaning up these options a bit, so that we can specify stop vs. rotate 
 and file size rather than capture time independently. 
 thoughts? I'm happy to accept the patch once sane, and then clean it up as 
 Guy suggests.
 
 
 Maybe it is time to work out how this should interact now...
 
 Why is there even a need to have -G and -C?
 Aren't both really just the same feature? (file rotation)
 But with a different parameter?
 Why can't it be -C 1h,500M? (rotate after 500M or 1h)
 ... and so on.
 
 I think the We might want to... paragraph is right but that more thought
 is needed.

Whatever the decision is can we be sure that the various options (-G, -C and 
-W) are kept for backwards compatibility for a long time? I ask because I know 
of some places which are using -G to write packets in time sliced files and 
changing the semantics of that flag would cause mass chaos.

What has never been clear to me is how -G, -C and -W work together, so any way 
to simplify things there and make it clearer is welcome by me.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] -C option not working? FreeBSD 10.1

[Wesley Shields]

I've got a patch for this at 
https://github.com/wxsBSD/tcpdump/commit/84998745a29a0ffb3a680c29692c15426a1ce960.

Seems to work well but I would appreciate any testing anyone can do. I'm also 
going to make sure this is right from the capsicum perspective as I have no 
experience with that. Once I discuss it with those folks I'll send a pull 
request.

On a somewhat related note, how is -G, -W and -C supposed to work together. The 
man page makes it sound like you can use all three together, but I'm not able 
to get anything to work. I would expect to do this:

tcpdump -i em0 -G 5 -W 5 -C 1 -w foo.pcap

and get foo.pcap0, foo.pcap1, foo.pcap2, foo.pcap3, foo.pcap4. Each output file 
should have 5 seconds worth of packets in them and then rotated. I can't seem 
to get this behavior.

-- WXS

 On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote:
 
 Hello all,
 
 Firstly, apologies if I missed info about this from a FAQ, documentation,
 source README and CHANGES and Google or if I am just doing something
 silly.  I looked at the man page and performed a Google and case sensitive
 searches via casesensitivesearch.com (to avoid all the -c results) but did
 not find any info about this issue I am having.
 
 I have built a host for circular recording of WAN traffic onto 2TB worth of
 storage, in order to hopefully catch pcaps after an event of intermittent
 issues we are not able to replicate.  Hoping that when a user complains and
 gives us the time of the issue, I can just grab a copy of the pre-recorded
 pcap which should contain the traffic associated with their issue.
 
 I've used FreeBSD 10.1 for this.  With the following tcpdump syntax as an
 example, run as root:
 
 tcpdump -C 1 -W 10 -w filename -i em0
 
 and I am finding that filename0 is created and captured to, but the capture
 does not roll over to the next file and instead continues to capture to the
 first file beyond the limit I thought would be imposed with -C 1, until I
 kill the process.
 
 I have tried the -Z option with -Z root, in case the issue was that a new
 file cannot be created once privs are dropped, but I get the same result.
 
 Thank you for reading and any help that you can give!
 
 
 Shane
 ___
 tcpdump-workers mailing list
 tcpdump-workers@lists.tcpdump.org
 https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] -C option not working? FreeBSD 10.1

[Wesley Shields]

Thanks! I've submitted a pull request (please ignore my first one, it was made 
on the master branch of my fork).

https://github.com/the-tcpdump-group/tcpdump/pull/433

I'm still not clear how -G, -C and -W are meant to work together though. The 
manage is a bit unclear to me. Any pointers on how it is supposed to work so I 
can try and make sure that is true would be appreciated.

-- WXS

 On Feb 18, 2015, at 4:23 PM, Guy Harris g...@alum.mit.edu wrote:
 
 
 On Feb 18, 2015, at 10:18 AM, Wesley Shields w...@freebsd.org wrote:
 
 I've got a patch for this at 
 https://github.com/wxsBSD/tcpdump/commit/84998745a29a0ffb3a680c29692c15426a1ce960.
 
 I've checked into the trunk a change to check for pcap_dump_ftell() failing 
 (which it should *always* have done; had it done that, the symptoms of this 
 problem would have been a bit less obscure), so your changes might at least 
 need to get the indentation readjusted.
 

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] -C option not working? FreeBSD 10.1

[Wesley Shields]

Looks like the call to pcap_dump_ftell() is always returning -1 and setting 
errno to 93 (ENOTCAPABLE). This makes sense since I can only trigger it on 
FreeBSD, and if I disable capsicum support in config.h and rebuild then -C 
works as expected.

I'll take a look at this and send a PR, but you may be better off building it 
yourself and disabling capsicum for now.

-- WXS

 On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote:
 
 Hello all,
 
 Firstly, apologies if I missed info about this from a FAQ, documentation,
 source README and CHANGES and Google or if I am just doing something
 silly.  I looked at the man page and performed a Google and case sensitive
 searches via casesensitivesearch.com (to avoid all the -c results) but did
 not find any info about this issue I am having.
 
 I have built a host for circular recording of WAN traffic onto 2TB worth of
 storage, in order to hopefully catch pcaps after an event of intermittent
 issues we are not able to replicate.  Hoping that when a user complains and
 gives us the time of the issue, I can just grab a copy of the pre-recorded
 pcap which should contain the traffic associated with their issue.
 
 I've used FreeBSD 10.1 for this.  With the following tcpdump syntax as an
 example, run as root:
 
 tcpdump -C 1 -W 10 -w filename -i em0
 
 and I am finding that filename0 is created and captured to, but the capture
 does not roll over to the next file and instead continues to capture to the
 first file beyond the limit I thought would be imposed with -C 1, until I
 kill the process.
 
 I have tried the -Z option with -Z root, in case the issue was that a new
 file cannot be created once privs are dropped, but I get the same result.
 
 Thank you for reading and any help that you can give!
 
 
 Shane
 ___
 tcpdump-workers mailing list
 tcpdump-workers@lists.tcpdump.org
 https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] -C option not working? FreeBSD 10.1

[Wesley Shields]

I don't have an answer to your original question other than to say I just 
duplicated it on a FreeBSD host but not on OS X. Smells like a bug to me.

I've done something similar in the past using -G and writing to something like 
/packets/%Y/%m/%d/%H%M%S.pcap (assuming those directories exist). This way when 
you are given a time when the problem occurred you can jump to that specific 
file much easier. Though, if you have to find the start of the session it may 
be in an earlier file.

tcpdump -G 300 -w /packets/%Y/%m/%d/%H%M%S.pcap

-- WXS

 On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote:
 
 Hello all,
 
 Firstly, apologies if I missed info about this from a FAQ, documentation,
 source README and CHANGES and Google or if I am just doing something
 silly.  I looked at the man page and performed a Google and case sensitive
 searches via casesensitivesearch.com (to avoid all the -c results) but did
 not find any info about this issue I am having.
 
 I have built a host for circular recording of WAN traffic onto 2TB worth of
 storage, in order to hopefully catch pcaps after an event of intermittent
 issues we are not able to replicate.  Hoping that when a user complains and
 gives us the time of the issue, I can just grab a copy of the pre-recorded
 pcap which should contain the traffic associated with their issue.
 
 I've used FreeBSD 10.1 for this.  With the following tcpdump syntax as an
 example, run as root:
 
 tcpdump -C 1 -W 10 -w filename -i em0
 
 and I am finding that filename0 is created and captured to, but the capture
 does not roll over to the next file and instead continues to capture to the
 first file beyond the limit I thought would be imposed with -C 1, until I
 kill the process.
 
 I have tried the -Z option with -Z root, in case the issue was that a new
 file cannot be created once privs are dropped, but I get the same result.
 
 Thank you for reading and any help that you can give!
 
 
 Shane
 ___
 tcpdump-workers mailing list
 tcpdump-workers@lists.tcpdump.org
 https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] File rotation every x seconds AND max file count

[Wesley Shields]

I believe daemonlogger can do this. It's been a while since I looked at
it but I believe that is what I added support for years ago.

http://sourceforge.net/projects/daemonlogger/

-- WXS

On Thu, Oct 16, 2014 at 01:21:57AM -0700, Cosmin T wrote:
 Hello,
 
 I wanted to create a pcap buffer of 2 hours based on 60 second
 slices. I hoped to achieve this by specifying -G 60 -W 120 (1 file
 every minute, 120 minutes). But of course, after reaching the 120 file
 count, tcpdump exits.
 
 Do you plan on implementing a way of doing the above?
 
 Thank you,
 Cosmin
 ___
 tcpdump-workers mailing list
 tcpdump-workers@lists.tcpdump.org
 https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: FreeBSD Port: git-2.0.1 unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

[Wesley Shields]

This comes up from time to time. I think most people solve it by
rebuilding docbook.

-- WXS

On Fri, Jul 18, 2014 at 02:06:40AM +0200, David wrote:
 Path: .
 Working Copy Root Path: /usr/ports
 URL: https://svn0.eu.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: https://svn0.eu.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 362166
 Node Kind: directory
 Schedule: normal
 Last Changed Author: thierry
 Last Changed Rev: 362166
 Last Changed Date: 2014-07-17 23:17:48 +0200 (Thu, 17 Jul 2014)
 
 I/O error : Attempt to load network entity 
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
 warning: failed to load external entity 
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
 compilation error: file /tmp/xmlto-xsl.0LLyQ9 line 4 element import
 xsl:import : unable to load 
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
 gmake[2]: *** [git-subtree.1] Error 1
 gmake[2]: Leaving directory 
 `/usr/ports/devel/git/work/git-2.0.1/contrib/subtree'
 *** Error code 2
 
 Stop.
 make[1]: stopped in /usr/ports/devel/git
 *** Error code 1
 
 


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: FreeBSD Port: git-2.0.1 unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

[Wesley Shields]

Ugh, I thought I thoroughly tested this update. I don't think the
problem is related to OpenSSL from ports at all. I botched the plist
somewhere. I'll take a look at this tomorrow and hopefully get a fix in.

Sorry for the noise, my testing systems have recently undergone some major
changes.

-- WXS

On Wed, Jul 23, 2014 at 03:16:50AM +0200, David wrote:
 It worked! Thanks. But now I get this instead.
 
 ===  Checking if devel/git already installed
 ===   Registering installation for git-2.0.2
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-http-fetch):
  
 No such file or directory
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-http-push):
  
 No such file or directory
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-http):
  
 No such file or directory
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-https):
  
 No such file or directory
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-ftp):
  
 No such file or directory
 pkg-static: 
 lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-ftps):
  
 No such file or directory
 *** Error code 74
 
 Stop.
 make[1]: stopped in /usr/ports/devel/git
 *** Error code 1
 
 Stop.
 make: stopped in /usr/ports/devel/git
 
 (I'm trying to use openssl from ports if that might be causing this.)
 
 On 2014-07-22 16:01, Gary J. Hayers wrote:
  I get this error all the time, could you expand on reinstalling 
  docbook as I did this and still get the same error.
 
  Many thanks,
  Gary
 
  On 22/07/2014 14:01, Wesley Shields wrote:
  This comes up from time to time. I think most people solve it by
  rebuilding docbook.
 
  -- WXS
 
  On Fri, Jul 18, 2014 at 02:06:40AM +0200, David wrote:
  Path: .
  Working Copy Root Path: /usr/ports
  URL: https://svn0.eu.freebsd.org/ports/head
  Relative URL: ^/head
  Repository Root: https://svn0.eu.freebsd.org/ports
  Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
  Revision: 362166
  Node Kind: directory
  Schedule: normal
  Last Changed Author: thierry
  Last Changed Rev: 362166
  Last Changed Date: 2014-07-17 23:17:48 +0200 (Thu, 17 Jul 2014)
 
  I/O error : Attempt to load network entity
  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
  warning: failed to load external entity
  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; 
 
  compilation error: file /tmp/xmlto-xsl.0LLyQ9 line 4 element import
  xsl:import : unable to load
  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
  gmake[2]: *** [git-subtree.1] Error 1
  gmake[2]: Leaving directory
  `/usr/ports/devel/git/work/git-2.0.1/contrib/subtree'
  *** Error code 2
 
  Stop.
  make[1]: stopped in /usr/ports/devel/git
  *** Error code 1
 
 
 
 
  ___
  freebsd-ports@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
  To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 
 
 
 


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

[tcpdump-workers] Extend libpcap tcpflags definition

[Wesley Shields]

I've been trying to come up with a good way to finish the work done in
this pull request:

https://github.com/the-tcpdump-group/libpcap/pull/300

I've been having a hard time coming up with a way that works, and I'm
curious if anyone else has suggestions.

We can always commit the definitions for tcp-ece and tcp-cwr, but if we
want to be able to reference tcp-ns (the last bit of the 12th byte of a
TCP header) we will have to change tcpflags to 12:2 (it is currently
13th byte).

Another option is to define an ext-tcpflags (or some other name, I
really don't care) as the 12th byte and reference it as
tcp[ext-tcpflags:2] if you want to look at tcp-ns.

At this point I'm open to suggestions.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] website not updated

[Wesley Shields]

If tcpdump 4.4.0 and libpcap 1.4.0 are done should the webpage be
updated or are they in some kind of beta form? I'll happily fix it on
github if that's the right place to do it.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] tcpdump 4.4 release candidate 1

[Wesley Shields]

On Mon, Mar 25, 2013 at 02:42:07PM -0400, Wesley Shields wrote:
 On Sun, Mar 24, 2013 at 05:52:51PM -0400, Michael Richardson wrote:
  
   Romain == Romain Francoise rom...@orebokech.com writes:
   please expect a new release candidate on 2013-03-09, assuming I
   can get enough Internet in St.Johns.
  
  Romain Not sure if this was St John's in Antigua or St John's in
  Romain Canada, hopefully the former this time of year (but most
  Romain likely the latter). :-)
  
  It was a 7000km of air travel for a 2300km trip thanks to snow at LGA.
  Very tiring.
  
  Romain In any case the rc2 tarballs are nowhere to be found. Can we
  Romain get an update, please?
  
  http://www.ca.tcpdump.org/beta/
 
 Picking a random spot in this thread to chime in but I've heard reports
 via co-workers that hitting ^C while handling multiple input files via
 'find | tcpdump -V -' doesn't work as expected. I'm trying to find time
 to look into this before the 4.4.0 release.

Hopefully it's not too late to get https://github.com/mcr/tcpdump/pull/60
merged in to 4.4.0.

Prior to the fix mentioned above if you hit ^C while doing

find /pcaps -type f | tcpdump -V - -w foo.pcap

it would stop processing the current file and move on to the next one in
the list. With this fix it stops processing the entire list and exits
normally.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] tcpdump 4.4 release candidate 1

[Wesley Shields]

On Sun, Mar 24, 2013 at 05:52:51PM -0400, Michael Richardson wrote:
 
  Romain == Romain Francoise rom...@orebokech.com writes:
  please expect a new release candidate on 2013-03-09, assuming I
  can get enough Internet in St.Johns.
 
 Romain Not sure if this was St John's in Antigua or St John's in
 Romain Canada, hopefully the former this time of year (but most
 Romain likely the latter). :-)
 
 It was a 7000km of air travel for a 2300km trip thanks to snow at LGA.
 Very tiring.
 
 Romain In any case the rc2 tarballs are nowhere to be found. Can we
 Romain get an update, please?
 
 http://www.ca.tcpdump.org/beta/

Picking a random spot in this thread to chime in but I've heard reports
via co-workers that hitting ^C while handling multiple input files via
'find | tcpdump -V -' doesn't work as expected. I'm trying to find time
to look into this before the 4.4.0 release.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted

[Wesley Shields]

On Thu, Mar 21, 2013 at 01:03:56PM -0400, Bill Fenner wrote:
 On Mon, Mar 18, 2013 at 11:08 PM, Wesley Shields w...@freebsd.org wrote:
  On Fri, Mar 15, 2013 at 06:37:25PM -0700, Guy Harris wrote:
 
  On Mar 15, 2013, at 2:45 PM, Michael Richardson m...@sandelman.ca wrote:
 
  
   wen == wen lui esolvepol...@gmail.com writes:
  wen I used libpcap function pcap_next() to capture some tcp packets
  wen I checked the bytes of the captured packets and notice that the
  wen ethernet and ip header of packets are distorted, in a mess with
  wen a lot 0's but the TCP header is fine
  
  wen what are potential reasons for this?
  
   if you capture on Linux with the cooked mode interface.
 
  That probably won't happen if you're capturing on an Ethernet device,
  but it *will* happen if you capture on the any device.
 
  However, yes, *NO* program using libpcap/WinPcap should simply
  *assume* it's getting Ethernet packets; if it's looking at the
  packets, not just blindly writing them to a file without examining the
  contents, then, if it doesn't need to handle 802.11 and PPP and so on,
  just Ethernet, it should at least call pcap_datalink() and fail if the
  return value isn't DLT_EN10MB.  (If it's writing them to a pcap file,
  pcap_dump_open() will call pcap_datalink() for you, to put the right
  link-layer header type in the file header.)
 
  (Should we change libpcap so that if pcap_datalink() isn't called at
  least once before calling pcap_next(), pcap_next_ex(),
  pcap_dispatch(), or pcap_loop(), it prints a message to the standard
  error saying you're probably assuming all the world is Ethernet,
  aren't you? and calls abort(). :-))
 
  As I'm not sure if you're serious or not I decided to look into this to
  satisfy my own curiosity. In case you are serious:
 
  https://github.com/wxsBSD/libpcap/commit/70cbe36e2bd12498ca1622349ecb1716a874c376
 
  If you are serious and want this I'll submit a pull request.
 
 Since pcap_compile() calls pcap_datalink(), I don't think that this
 will have as much affect as Guy was imagining.

I noticed that. I think I mentioned it in commit.

 (Now introduce an argument to pcap_datalink() that says I'm calling
 you from pcap_compile(), and ... ;-)

That would be breaking a lot of existing applications.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted

[Wesley Shields]

On Fri, Mar 15, 2013 at 06:37:25PM -0700, Guy Harris wrote:
 
 On Mar 15, 2013, at 2:45 PM, Michael Richardson m...@sandelman.ca wrote:
 
  
  wen == wen lui esolvepol...@gmail.com writes:
 wen I used libpcap function pcap_next() to capture some tcp packets
 wen I checked the bytes of the captured packets and notice that the
 wen ethernet and ip header of packets are distorted, in a mess with
 wen a lot 0's but the TCP header is fine
  
 wen what are potential reasons for this?
  
  if you capture on Linux with the cooked mode interface.
 
 That probably won't happen if you're capturing on an Ethernet device,
 but it *will* happen if you capture on the any device.
 
 However, yes, *NO* program using libpcap/WinPcap should simply
 *assume* it's getting Ethernet packets; if it's looking at the
 packets, not just blindly writing them to a file without examining the
 contents, then, if it doesn't need to handle 802.11 and PPP and so on,
 just Ethernet, it should at least call pcap_datalink() and fail if the
 return value isn't DLT_EN10MB.  (If it's writing them to a pcap file,
 pcap_dump_open() will call pcap_datalink() for you, to put the right
 link-layer header type in the file header.)
 
 (Should we change libpcap so that if pcap_datalink() isn't called at
 least once before calling pcap_next(), pcap_next_ex(),
 pcap_dispatch(), or pcap_loop(), it prints a message to the standard
 error saying you're probably assuming all the world is Ethernet,
 aren't you? and calls abort(). :-))

As I'm not sure if you're serious or not I decided to look into this to
satisfy my own curiosity. In case you are serious:

https://github.com/wxsBSD/libpcap/commit/70cbe36e2bd12498ca1622349ecb1716a874c376

If you are serious and want this I'll submit a pull request.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: I need help with git

[Wesley Shields]

On Tue, Feb 05, 2013 at 11:30:43AM +1030, Shane Ambler wrote:
 
 
  GH_COMMIT=  4dfdc80
 
  Probably not needed if you specify a tag other than master.
 
  If I pull master, I get commit f57e464.  That's not what I want.
  Why doesn't this thing pull the commit I'm telling it to pull?
 
 I think the thing most people miss here is that GH_COMMIT doesn't
 effect what gets downloaded, it's not used like an svn rev number
 - it is only used to define WRKSRC
 
 When a github tarball gets extracted GH_COMMIT is part of the dir name.
 
 Which is why it is mandatory and needs to match the tag. It is just
 needed to work with the way github creates tarballs. It is inconvenient
 but github is only setup to let you download tarballs of specific tags
 not specific commits. If the main devs don't tag the specific points you
 want the only option is to fork and create your own tags.

I don't know if we have a way to express this in the ports framework but
you absolutely can grab a tarball of a repo at any specific commit on
github even if it is not tagged.

This is the URL to grab ironbee/libhtp at
234fd5bab1225e483ea263a5a15faebed0bd61b9:

https://github.com/ironbee/libhtp/archive/234fd5bab1225e483ea263a5a15faebed0bd61b9.tar.gz

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Problems with GITHUB pulls

[Wesley Shields]

On Tue, Jan 29, 2013 at 03:24:31PM -0600, Paul Schmehl wrote:
 I maintain the security/barnyard2 port.  It pulls the software from git, 
 which is the only place where it's available.
 
 Here's the relevant portion of the port's Makefile:
 
 USE_GITHUB= yes
 GH_ACCOUNT= firnsy
 GH_PROJECT= ${PORTNAME}
 GH_TAGNAME= master
 GH_COMMIT= 4dfdc80
 
 The problem is, master's commit tag and md5 sum and size have changed.  I 
 *could* update the port by changing the commit tag and the distino file, 
 but that's seems rather kludgy to me.  The version hasn't changed.  The 
 developers simply fixed some problems in the software and then bumped 
 master to the newer commit.

The point of GH_COMMIT is to checkout a specific commit. I think you
don't need GH_TAGNAME set here as that is probably overriding the
desired behavior (and always fetching the latest from master). For an
idea of how to fetch a specific commit from git check out devel/libhtp.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Problems with GITHUB pulls

[Wesley Shields]

On Tue, Jan 29, 2013 at 10:10:13PM -0500, Wesley Shields wrote:
 On Tue, Jan 29, 2013 at 03:24:31PM -0600, Paul Schmehl wrote:
  I maintain the security/barnyard2 port.  It pulls the software from git, 
  which is the only place where it's available.
  
  Here's the relevant portion of the port's Makefile:
  
  USE_GITHUB= yes
  GH_ACCOUNT= firnsy
  GH_PROJECT= ${PORTNAME}
  GH_TAGNAME= master
  GH_COMMIT= 4dfdc80
  
  The problem is, master's commit tag and md5 sum and size have changed.  I 
  *could* update the port by changing the commit tag and the distino file, 
  but that's seems rather kludgy to me.  The version hasn't changed.  The 
  developers simply fixed some problems in the software and then bumped 
  master to the newer commit.
 
 The point of GH_COMMIT is to checkout a specific commit. I think you
 don't need GH_TAGNAME set here as that is probably overriding the
 desired behavior (and always fetching the latest from master). For an
 idea of how to fetch a specific commit from git check out devel/libhtp.

I think I might have completely misspoken here. What's happening is you
are fetching master at the appropriate commit, but distinfo is getting
the filename with the DISTVERSION string in it. When you update to the
next commit the DISTVERSION isn't changing and thus distinfo is now out
of date.

The best way to approach this is as was suggested by someone else. Get
upstream to tag releases and use those. The way you are doing it you
will have to set a PORTVERSION that is not accurate at all and bump
PORTREVISION everytime you update.

The devel/libhtp port is using a very old tag because upstream has not
tagged a new version in the last 7 months and I don't want to end up in
the situation you are experiencing.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: databases/mongodb fails to start, assertion failure in unit test

[Wesley Shields]

On Sat, Jan 26, 2013 at 07:06:21AM -0800, Waitman Gobble wrote:
 Waitman Gobble uzi...@da3m0n8t3r.com wrote ..
  
  Hi,
  
  I've installed databases/mongodb and get an error when starting.
  
  # /usr/local/etc/rc.d/mongod start
  Starting mongod.
  forked process: 59576
  all output going to: /var/db/mongodb/mongod.log
  /usr/local/etc/rc.d/mongod: WARNING: failed to start mongod
  
  # cat /var/db/mongodb/mongod.log
  
  Fri Jan 25 00:30:57   Assertion failure l  bigl src/mongo/db/btree.cpp 1973
  0x5a503d 0x5eb41d 0x74dce9 0x547638 0x545ed9 0x542bc1 
   0x5a503d _ZN5mongo12verifyFailedEPKcS1_j+285 at /usr/local/bin/mongod
   0x5eb41d _ZN5mongo10BTUnitTest3runEv+333 at /usr/local/bin/mongod
   0x74dce9 _ZN5mongo11StartupTest8runTestsEv+57 at /usr/local/bin/mongod
   0x547638 main+5992 at /usr/local/bin/mongod
   0x545ed9 main+9 at /usr/local/bin/mongod
   0x542bc1 _start+145 at /usr/local/bin/mongod
  Fri Jan 25 00:30:57 Got signal: 6 (Abort trap: 6).
  
  
  
  # portversion -v mongodb
  mongodb-2.2.0_1 =  up-to-date with port
  
  # uname -a
  FreeBSD kamira.waitman.net 9.1-STABLE FreeBSD 9.1-STABLE #0 r245772M: Tue 
  Jan 22
  06:09:00 PST 2013 r...@kamira.waitman.net:/usr/obj/usr/src/sys/BURPLEX  
  amd64
  
  
  I added a couple lines to print the values before the failure.
  
  
  src/mongo/db/btree.h
  
  ..
  
  struct BTUnitTest : public StartupTest {
  void run() {
  DiskLoc big(0xf12312, 0x70001234);
  DiskLoc56Bit bigl;
  {
  bigl = big;
  verify( big == bigl );
  DiskLoc e = bigl;
  verify( big == e );
  }
  {
  DiskLoc d;
  verify( d.isNull() );
  DiskLoc56Bit l;
  l = d;
  verify( l.isNull() );
  d = l;
  verify( d.isNull() );
  
  printf(bigl %s\n,bigl.toString().c_str());
  printf(l %s\n,l.toString().c_str());
  
  verify( l  bigl );
  }
  }
  } btunittest;
  ..
  
  
  output:
 
  bigl f12312:70001234
  l null
  Thu Jan 24 23:18:17   Assertion failure l  bigl src/mongo/db/btree.cpp 1978
 
  
  looking at
  src/mongo/db/diskloc.h
 
  bool isNull() const { return _a == -1; }
  ..   
  int compare(const DiskLoc b) const {
  int x = _a - b._a;
  if ( x )
  return x;
  return ofs - b.ofs;
  }
  bool operator(const DiskLoc b) const {
  return compare(b)  0;
  }
  ..
  void Null() {
  _a = -1;
  ofs = 0; /* note NullOfs is different. todo clean up.  see refs 
  to
  NullOfs in code - use is valid but outside DiskLoc context so confusing 
  as-is.
  */
  }
  
  
 
  it seems that this should be working!
  
  test model:
  
  #include stdio.h
  
  int
  compare (int a, int b)
  {
  int x = a - b;
  if ( x )
  return x;
  return 555;
  }
  
  bool
  ncompare (int a, int b)
  {
  return compare(a,b)  0;
  }
  
  int
  main (void)
  {
  int a, b;
  a = -1;
  b = 0xf12312;
  int c = a - b;
  printf(%d\n,c);
  c = compare(a,b);
  printf(%d\n,c);
  bool d = ncompare(a,b);
  printf(%d\n,d);
  bool e = ncompare(b,a);
  printf(%d\n,e);
  return 0;
  }
  
  # clang++ -o test test.cpp
  # ./test
  -15803155
  -15803155
  1
  0
  
  
  I'm missing something...
   
  Suggestions, tips, hints much appreciated. 
  
  Thanks,
  
  -- 
  Waitman Gobble
  San Jose California USA
 
 Hi,
 
 I've tinkered around with this problem. Commenting out the 'verify( l
  bigl );' line in src/mongo/db/btree.h solves the assertion failure
 problem, and mongodb starts and runs. However, after reviewing the
 code it seems this 'start' unit test is only actually testing if the
 thing can 'subtract integers.' I'm very puzzled as to why it is
 failing, it's bombing out when it does 'verify ((-1 - 0xf12312)0)'.
 which seems trivial.
 
 The code that runs the unit test/StartupTest is simple, but i haven't
 yet found the 'verify' macro, at least i believe it's a macro. 
 
 Anyhow, commenting out the test line gets mongodb running, but I'm
 wondering what other problems there could be. (?) 
 
 I found that compiling with base gcc avoids the startup problem, so
 this indeed seems to be an issue related to building with clang. clang
 builds mongodb without error, however running the mongodb compiled
 with clang fails during 'startuptest'. 
 
 IMHO It would be good to track down the problem, at least understand
 the cause, but at this moment it seems like compiling mongodb with gcc
 is the way to go.
 
 I've updated the port to use the latest release/ 2.2.2 version of
 mongodb, I'll submit a PR in a bit, (it does not appear to have 

Re: [tcpdump-workers] Decoding the unencrypted part(s) of SSL/TLS?

[Wesley Shields]

On Mon, Dec 10, 2012 at 11:38:29PM -0500, Michael Richardson wrote:
 
  Rick == Rick Jones rick.jon...@hp.com writes:
 Rick Is there a version of tcpdump in the works which will decode
 Rick the unecrypted 
 Rick portions of an SSL/TLS session?  Or do I need to look
 Rick elsewhere?

Are you asking if there is a decoder for the SSL/TLS handshakes or are
you asking if there is something that will, given a private key, decrypt
the SSL?

 Yes/no.
 You have, in general, to do TCP reassembly as TLS blocks might span TCP
 segments. 
 
 Fortunately, you can use: http://www.rtfm.com/ssldump/
 to do exactly that.

There are some problems with ssldump when building on newer-ish systems
(at least I think there were last time I tried to use it). If you can
get it to work it is good.

 It takes pcap files.  It even decrypts if you give it the keys.

Another option is to use tshark. I'm not a fan of it but it does work in
a pinch.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: Fwd: FreeBSD ports you maintain which are out of date

[Wesley Shields]

On Wed, Dec 05, 2012 at 01:59:49AM +0800, Yanhui Shen wrote:
 -- Forwarded message --
 From: Yanhui Shen shen@gmail.com
 Date: 2012/12/5
 Subject: Re: FreeBSD ports you maintain which are out of date
 To: portsc...@portscout.freebsd.org
 
 
 Hi,
 
 According to this page http://basiccoder.com/openfetion
 The OpenFetion Project is deprecated,
 and therefore I do not want to maintain it any more. :-(
 
 Actually,  there is a 2.2.1 port, but I think the software itself is buggy.
 The most annonying problem is, it'll be offline when shortmsg arrived. (100%)
 
 So, in my opinion what about just remove it from the ports tree?

I will set an expiration date of one month from now and remove the port
then. Thanks for bringing this to our attention.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: databases/mongodb on FreeBSD 9

[Wesley Shields]

On Fri, Nov 30, 2012 at 06:22:28AM -0800, Patrick wrote:
 Has anyone had any issues building the mongodb port on FreeBSD 9?
 
 I'm running 9.0-RELEASE-p5 on i386:
 
 It's bailing for me here:
 
 c++ -o
 build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o
 -c -Wnon-virtual-dtor -Woverloaded-virtual -fno-omit-frame-pointer -fPIC
 -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare
 -Wno-unknown-pragmas -Winvalid-pch -O3 -D_SCONS -DMONGO_EXPOSE_MACROS
 -DSUPPORT_UTF8 -D__freebsd__ -D_FILE_OFFSET_BITS=64 -DJS_C_STRINGS_ARE_UTF8
 -DMONGO_SSL -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_EXECINFO_BACKTRACE
 -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm -Isrc
 -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo
 -Isrc/mongo
 -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/cpp
 -Isrc/mongo/cpp -I/usr/local/include src/mongo/shell/linenoise.cpp
 In file included from src/mongo/shell/linenoise.cpp:115:
 src/mongo/shell/linenoise_utf8.h: In member function 'void
 linenoise_utf8::UtfStringMixinchar_type::swap(linenoise_utf8::UtfStringMixinchar_type)':
 src/mongo/shell/linenoise_utf8.h:145: error: 'swap' is not a member of 'std'
 src/mongo/shell/linenoise_utf8.h:146: error: 'swap' is not a member of 'std'
 src/mongo/shell/linenoise_utf8.h:147: error: 'swap' is not a member of 'std'
 scons: ***
 [build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o]
 Error 1
 scons: building terminated because of errors.
 *** Error code 2

It builds fine for me. Can you check what version of boost and it's
related packages you are building against?

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: was: portsnap down.. cvs broken?

[Wesley Shields]

On Tue, Nov 13, 2012 at 09:45:51AM -0800, Jeffrey Bouquet wrote:
 Reply below...? 
 
 --- On Mon, 11/12/12, Christoph Moench-Tegeder c...@burggraben.net wrote:
 
 From: Christoph Moench-Tegeder c...@burggraben.net
 Subject: portsnap down?
 To: freebsd-ports@FreeBSD.org
 Date: Monday, November 12, 2012, 11:33 PM
 
 Hi,
 
 as I saw noone complaining until right now (and didn't find any
 announcement about downtime): looks like portsnap does not provide
 new snapshots; if I'm reading the current snapshot tag correctly,
 it's from Sun Nov 11 15:54:03 CET 2012. The svnweb interface shows
 way more recent commits...
 Anyone to enlighten me or to nudge portsnap?
 
 Regards,
 Christoph
 
 -- 
 Spare Space
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 
 
 UPDATING is a broken link from freshports.org
 cvs/cvsup is not doing anything here for the last twelve hours or so...
 cvsweb is a broken link from freebsd.org
 
 UPDATING might have a clue (something about git) but I am unable to view
 it, as the cvs nor sites have access...

There is some work being done on the machines that provide these
services. The UPDATING entry you mention (the one about git) has nothing
to do with this.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

[HEADS UP]: CVE-2012-4929 (CRIME)

[Wesley Shields]

I think there is nothing FreeBSD can do about this besides making sure
our users are aware of it. The situation in which this is a problem is
specific but one you should consider if you are using TLS with
compression.

TLS 1.2 and earlier are vulnerable to an attack commonly known as CRIME.
The attack involves TLS sessions using compression where an attacker is
able to inject known plaintext into the stream. Through a series of
guesses and measuring the length of the encrypted text an attacker is
able to determine the plaintext.

The recommended workaround for now is to disable compression on servers
where this may have an impact. As this is a flaw in a protocol and no
one specific implementation please consult the documentation for any
affected services to determine how to turn off TLS compression.

More information is available at:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4929

-- WXS
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

[HEADS UP]: CVE-2012-4929 (CRIME)

[Wesley Shields]

I think there is nothing FreeBSD can do about this besides making sure
our users are aware of it. The situation in which this is a problem is
specific but one you should consider if you are using TLS with
compression.

TLS 1.2 and earlier are vulnerable to an attack commonly known as CRIME.
The attack involves TLS sessions using compression where an attacker is
able to inject known plaintext into the stream. Through a series of
guesses and measuring the length of the encrypted text an attacker is
able to determine the plaintext.

The recommended workaround for now is to disable compression on servers
where this may have an impact. As this is a flaw in a protocol and no
one specific implementation please consult the documentation for any
affected services to determine how to turn off TLS compression.

More information is available at:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4929

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Failed upgrade sudo-1.8.5.p3 to sudo-1.8.6.p3 running stable/9

[Wesley Shields]

On Wed, Sep 26, 2012 at 02:05:57PM -0700, David Wolfskill wrote:
 On Wed, Sep 26, 2012 at 04:59:28PM -0400, Wesley Shields wrote:
  On Wed, Sep 26, 2012 at 04:43:57AM -0700, David Wolfskill wrote:
   This is a FreeBSD/i386 stable/9 system:
   
   FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE 
   #485 240956M: Wed Sep 26 04:19:48 PDT 2012 
   r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386
   
   built with clang, but cc is gcc:
  
  This is a failure on i386 only, which is why I didn't notice it. Would
  you apply the patch available at [1] and let me know if it works. It
  does build for me now that I built up a i386 environment.
  
  [1]: http://people.freebsd.org/~wxs/sudo-ssp.diff
  
 
 Aye; builds  a trivial test:
 
 d134(9.1-P)[1] sudo id
 Password:
 uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
 d134(9.1-P)[2] 
 
 works. :-}

My original patch did not build correctly with clang. I've just
committed r304961 which works on both i386 and under clang.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: redports - should I rename the updated distfile (tarball)?

[Wesley Shields]

On Thu, Sep 27, 2012 at 12:55:51PM +0100, Anton Shterenlikht wrote:
 redports.org is good, thank you to whoever worked on it.
 
 One question: the upstream for my port is non-existent,
 so rather then patch it, I'm updating the code itself.
 I then create a new tarball. It seems redports doesn't
 update the tarball every time I request a build.
 So it seems I have to update the version in Makefile
 each time and create a tarball with this new number.
 Is that so?

I can't comment on the relation of this to redports as I've never used
it myself. I can state that if you're modifying the source and creating
a new tarball you should bump the PORTVERSION in the port (and
consequently in your distfile too) and also make sure distinfo is
correct. This will help to distinguish your changed tarball from the
original.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Failed upgrade sudo-1.8.5.p3 to sudo-1.8.6.p3 running stable/9

[Wesley Shields]

On Wed, Sep 26, 2012 at 04:43:57AM -0700, David Wolfskill wrote:
 This is a FreeBSD/i386 stable/9 system:
 
 FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #485 
 240956M: Wed Sep 26 04:19:48 PDT 2012 
 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386
 
 built with clang, but cc is gcc:

This is a failure on i386 only, which is why I didn't notice it. Would
you apply the patch available at [1] and let me know if it works. It
does build for me now that I built up a i386 environment.

[1]: http://people.freebsd.org/~wxs/sudo-ssp.diff

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: security/sudo: make fails after update to 1.8.6p3

[Wesley Shields]

On Wed, Sep 26, 2012 at 09:43:06PM +0900, Yasuhiro KIMURA wrote:
 From: ??ukasz W??sikowski luk...@wasikowski.net
 Subject: Re: security/sudo: make fails after update to 1.8.6p3
 Date: Wed, 26 Sep 2012 14:14:37 +0200
 
  W dniu 2012-09-26 13:57, Herbert J. Skuhra pisze:
  
  After update of security/sudo to 1.8.6p3, make fails on 9.0-RELEASE as
  following:
 
  [Several lines removed]
 
  Are there anyone alse experienced this?
  
  Yes, the port obviously builds only on amd64.
  
  True, I've installed it successfully on amd64 and got the same error on
  i386 box.
 
 Thanks. I found PR for this issue is already sent.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/172085
 
 So I'll wait for maintainer's reaction.

This patch [1] should suffice. Please test it out and let me know.

[1]: http://people.freebsd.org/~wxs/sudo-ssp.diff

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [tcpdump-workers] Multifile patch

[Wesley Shields]

On Thu, Sep 06, 2012 at 02:46:30PM -0400, Wesley Shields wrote:
 On Mon, Sep 03, 2012 at 10:13:57PM -0400, Michael Richardson wrote:
  
  Wesley, is fopen(/dev/stdin) really the most portal way to
  get a reference to stdin?  I'd have thought that doing:
  VFile=stdin;
  
  was the best way?
 
 I fixed this and your other comment about refactoring reading from the
 file.
 
 Please see my latest commit on github.
 
 https://github.com/wxsBSD/tcpdump/commit/4c2790a43252b9cac1fe7f6b50b51c3c55d2370a

No further comments so I issued a pull request.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Multifile patch

[Wesley Shields]

On Mon, Sep 03, 2012 at 10:13:57PM -0400, Michael Richardson wrote:
 
 Wesley, is fopen(/dev/stdin) really the most portal way to
 get a reference to stdin?  I'd have thought that doing:
 VFile=stdin;
 
 was the best way?

I fixed this and your other comment about refactoring reading from the
file.

Please see my latest commit on github.

https://github.com/wxsBSD/tcpdump/commit/4c2790a43252b9cac1fe7f6b50b51c3c55d2370a

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Multifile patch

[Wesley Shields]

On Thu, Aug 23, 2012 at 01:27:33PM -0400, Michael Richardson wrote:
 
  Wesley == Wesley Shields w...@freebsd.org writes:
  Since pcap files have no end of file marker, and each file
  has a header on it, do you look at the beginning of each packet, and 
 see
  if there is a pcap magic number?
 
 Wesley I'm not sure I'm parsing this right but...
 
 Wesley I am using pcap_open_offline() on each file, which should be 
 validating
 Wesley that I'm operating on a pcap file. I also check to ensure
 Wesley that the DLT
 
 Ah, sorry, you wrote:
   find /pcaps -type f | tcpdump -V - -w out.pcap
 
 so you are reading a list of files rather than concatenating them.
 I had read:
 
   find /pcaps -type f | xargs cat | tcpdump -V - -w out.pcap
 
 so you'd have a byte stream with multiple pcap headers inline.
 Do we support multipe -r flags... no... maybe that's a better fix?

I don't recall that being supported. I'm not sure what it would take to
do that either. My approach seemed easy enough to implement.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Multifile patch

[Wesley Shields]

On Tue, Aug 21, 2012 at 08:36:12PM -0400, Michael Richardson wrote:
 
 Wesley, it seems like a good idea.
 I can't look at your patch from the cottage, since I squirt out bits
 only once a day by walking down the road to where there is some wifi.

No worries, I'm in no rush on this. Enjoy your time away from the
internet.

 Since pcap files have no end of file marker, and each file
 has a header on it, do you look at the beginning of each packet, and see
 if there is a pcap magic number?

I'm not sure I'm parsing this right but...

I am using pcap_open_offline() on each file, which should be validating
that I'm operating on a pcap file. I also check to ensure that the DLT
of every subsequent file matches the DLT of the first file when using
this option in conjunction with -w, since we don't want to generate one
output file with multiple input DLTs.

-- WXS
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: Qestion about patching

[Wesley Shields]

On Mon, Aug 20, 2012 at 10:03:54AM +0800, HU Dong wrote:
 Hi!
 The porter's handbook says that Note that if the path of a patched
 file contains an underscore (_) character, the patch needs to have two
 underscores instead in its name. For example, to patch a file named
 src/freeglut_joystick.c, the corresponding patch should be named
 patch-src-freeglut__joystick.c.
 
 Question: What if the file contains -
 charactor(src/freeglut-joystick.c)? Should the patch be
 patch-src-freeglut-joystick.c or patch-src-freeglut--joystick.c?

When applying a patch I get from upstream I apply it manually in
${WRKSRC} and then use 'make makepatch' from the port directory to
generate the appropriate filename in files for me.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit

[Wesley Shields]

On Wed, Aug 08, 2012 at 10:34:06AM +, Alexey Dokuchaev wrote:
 On Mon, Aug 06, 2012 at 01:49:50PM +0200, Rainer Hurling wrote:
  Am 06.08.2012 10:03 (UTC+1) schrieb Doug Barton:
  On 08/01/2012 05:09, Oliver Pinter wrote:
  I found this today on FD:
  
  http://seclists.org/fulldisclosure/2012/Aug/4
  
  Apparently this affects us as well. Any news?
  
  Thanks for the info. I had been not aware of it before.
  
  NVidia has released a driver version 304.32 for FreeBSD i386 and amd64, 
  which should remedy these security issues.
 
 Luckily, they've released version 295.71 which is on Long Lived Branch.  I
 will update the port shortly.

Thank you!

 VuXML entry will have to follow separately, as it is unclear whether new CVE
 number will be assigned or not.

You can do the VuXML without a CVE for now and update it when/if one is
assigned.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: net/mosh conflicts with lang/mosh

[Wesley Shields]

On Thu, Aug 09, 2012 at 12:12:32AM +0800, Yanhui Shen wrote:
 Hi,
 
 net/mosh is a mobile terminal, while lang/mosh is a R6RS scheme interpreter,
 and both of them have bin/mosh.
 
 So is there any way to make both of them installed?
 Or actually, one of which needs to be renamed?

No decent way to have both of them installed under the same prefix. You
can always install one in a chroot somewhere.

One of them would need to rename bin/mosh to something else.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

cvs commit: ports/databases/mongodb Makefile distinfo ports/databases/mongodb/files patch-SConstruct

[Wesley Shields]

wxs 2012-07-13 20:48:50 UTC

  FreeBSD ports repository

  Modified files:
databases/mongodbMakefile distinfo 
databases/mongodb/files patch-SConstruct 
  Log:
  Update to 2.0.6.
  Convert to optionsNG
  
  PR: ports/169548
  Approved by:m...@derzinn.de (maintainer timeout)
  
  Revision  ChangesPath
  1.27  +8 -7  ports/databases/mongodb/Makefile
  1.22  +2 -2  ports/databases/mongodb/distinfo
  1.6   +4 -16 ports/databases/mongodb/files/patch-SConstruct
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/devel/arduino Makefile distinfo pkg-descr pkg-plist

[Wesley Shields]

wxs 2012-07-12 18:50:36 UTC

  FreeBSD ports repository

  Modified files:
devel/arduinoMakefile distinfo pkg-descr pkg-plist 
  Log:
  Update to 1.0.1.
  Convert to optionsNG.
  
  PR: ports/169790
  Submitted by:   wblock@ (maintainer)
  
  Revision  ChangesPath
  1.11  +11 -30ports/devel/arduino/Makefile
  1.7   +2 -2  ports/devel/arduino/distinfo
  1.4   +3 -0  ports/devel/arduino/pkg-descr
  1.8   +192 -148  ports/devel/arduino/pkg-plist
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/devel/arduino/files patch-hardware-arduino-cores-arduino-Print.cpp

[Wesley Shields]

wxs 2012-07-13 00:48:08 UTC

  FreeBSD ports repository

  Removed files:
devel/arduino/files  
 patch-hardware-arduino-cores-arduino-Print.cpp 
  Log:
  Remove file that should have been removed in previous commit.
  
  Approved by:wblock@ (maintainer)
  
  Revision  ChangesPath
  1.2   +0 -12 
ports/devel/arduino/files/patch-hardware-arduino-cores-arduino-Print.cpp (dead)
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/mail/dovecot2 Makefile

[Wesley Shields]

wxs 2012-07-10 12:57:48 UTC

  FreeBSD ports repository

  Modified files:
mail/dovecot2Makefile 
  Log:
  Remove unnecessary gssapi replacement.
  
  Approved by:Attila Nagy b...@fsn.hu
  
  Revision  ChangesPath
  1.20  +0 -5  ports/mail/dovecot2/Makefile
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/mail/dovecot Makefile

[Wesley Shields]

wxs 2012-07-09 19:24:21 UTC

  FreeBSD ports repository

  Modified files:
mail/dovecot Makefile 
  Log:
  Don't check WITH_FOO  !WITHOUT_FOO. [1]
  Remove gssapi patch that is no longer needed. [2]
  
  These both apply to mail/dovecot2 also. I will be working with the
  maintainer there to get these committed.
  
  PR: ports/167824 [1]
  ports/
  Submitted by:   Dmitry Afanasiev k...@matpockuh.ru [1]
  Leon Messner l.mess...@physik.tu-berlin.de [2]
  Approved by:maintainer timeout
  
  Revision  ChangesPath
  1.121 +9 -14 ports/mail/dovecot/Makefile
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/devel/git Makefile distinfo pkg-plist

[Wesley Shields]

wxs 2012-07-07 03:07:57 UTC

  FreeBSD ports repository

  Modified files:
devel/gitMakefile distinfo pkg-plist 
  Log:
  Update to 1.7.11.1
  Convert to optionsNG
  Fix updating /etc/shells when using the package [1]
  
  Submitted by:   Marin Atanasov Nikolov [1]
  
  Revision  ChangesPath
  1.140 +47 -38ports/devel/git/Makefile
  1.102 +6 -6  ports/devel/git/distinfo
  1.103 +39 -3 ports/devel/git/pkg-plist
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/devel/php-xdebug Makefile distinfo

[Wesley Shields]

wxs 2012-07-02 19:51:24 UTC

  FreeBSD ports repository

  Modified files:
devel/php-xdebug Makefile distinfo 
  Log:
  Update to 2.2.0 and work on php54.
  
  PR: ports/168583
  Submitted by:   Oleg Ginzburg olev...@olevole.ru
  Approved by:Bill Moran wmo...@collaborativefusion.com (maintainer)
  
  Revision  ChangesPath
  1.26  +2 -4  ports/devel/php-xdebug/Makefile
  1.19  +2 -2  ports/devel/php-xdebug/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/security/vuxml vuln.xml

[Wesley Shields]

wxs 2012-07-02 20:05:25 UTC

  FreeBSD ports repository

  Modified files:
security/vuxml   vuln.xml 
  Log:
  Document phplist SQL injection and XSS.
  
  Submitted by:   Krzysztof Stryjek w...@bsdserwis.com
  
  Revision  ChangesPath
  1.2748+35 -1 ports/security/vuxml/vuln.xml
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/mail/phplist Makefile distinfo

[Wesley Shields]

wxs 2012-07-03 02:06:24 UTC

  FreeBSD ports repository

  Modified files:
mail/phplist Makefile distinfo 
  Log:
  Update to 2.10.18
  
  PR: ports/169600
  Submitted by:   Krzysztof Stryjek po...@bsdserwis.com (maintainer)
  Security:   fd8bac56-c444-11e1-864b-001cc0877741
  
  Revision  ChangesPath
  1.11  +1 -1  ports/mail/phplist/Makefile
  1.7   +2 -2  ports/mail/phplist/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

Re: Can I get some love on this PR?

[Wesley Shields]

On Mon, Jul 02, 2012 at 12:55:28PM -0400, Bill Moran wrote:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168583
 
 This bugger is about a month old at this point.  Of course,
 part of that is my fault for being slow to respond, so I'm
 just putting a heads-up out -- if anyone is able to commit
 that, it'd be great.

I'll grab it, unless sylvio@ speaks up and says he's going to commit it
soon.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: cvs commit: ports/security/vuxml vuln.xml

[Wesley Shields]

On Wed, Jun 27, 2012 at 03:34:44PM +, Ryan Steinmetz wrote:
 zi  2012-06-27 15:34:44 UTC
 
   FreeBSD ports repository
 
   Modified files:
 security/vuxml   vuln.xml 
   Log:
   - Document recent FreeBSD SA's for 2012: SA-12:04.sysret,
   SA-12:03.bind, SA-12:02.crypt, SA-12:01.openssl
   
   Reviewed by:wxs

Thanks! I had been meaning to do this but keep running out of time to do
it.

It would be nice if these were prepared by someone(TM) and committed
along with the fixes. Getting these out to portaudit users is a useful
thing to do. I don't want to add on to secteam's work but I do want to
at least bring it up as something we should formalize for SAs.

Before anyone asks: yes, if I knew about SAs going out ahead of time I
would make sure I prepare the updates to go in time. It's just so
annoying to do after-the-fact that I kept putting it off.

-- WXS
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/ports-mgmt/psearch Makefile distinfo

[Wesley Shields]

wxs 2012-06-25 16:44:28 UTC

  FreeBSD ports repository

  Modified files:
ports-mgmt/psearch   Makefile distinfo 
  Log:
  Update to 2.0.2
  
  PR: ports/169078
  Submitted by:   Kimmo Paasiala kpaas...@gmail.com
  Approved by:Benjamin Lutz m...@maxlor.com (maintainer)
  
  Revision  ChangesPath
  1.7   +1 -1  ports/ports-mgmt/psearch/Makefile
  1.7   +2 -2  ports/ports-mgmt/psearch/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

Re: ports/169078

[Wesley Shields]

On Mon, Jun 25, 2012 at 06:24:22PM +0300, Kimmo Paasiala wrote:
 Hi,
 
 I wrote a small fix for ports-mgmt/psearch some time ago and I
 submitted a bug report
 http://www.freebsd.org/cgi/query-pr.cgi?pr=169078 and the maintainer
 of the port rolled out a new distfile for a new version but the fix
 hasn't been yet committed to the ports tree. Could someone commit
 this?

I've grabbed this PR and will be committing the update to 2.0.2 shortly.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

cvs commit: ports/sysutils Makefile ports/sysutils/bsdinfo Makefile distinfo pkg-descr

[Wesley Shields]

wxs 2012-06-22 13:54:24 UTC

  FreeBSD ports repository

  Modified files:
sysutils Makefile 
  Added files:
sysutils/bsdinfo Makefile distinfo pkg-descr 
  Log:
  This is a FreeBSD attempt to implement archey-like terminal system information
  display utility. It is just an esthetic way to display system information.
  Right now it doesn't have any configurable options (different themes, switches
  to change behaviour, etc), but I will add such features in the future, 
perhaps.
  
  WWW: https://github.com/samaelszafran/bsdinfo
  
  PR: ports/168832
  Submitted by:   s...@samu.pl
  
  Revision  ChangesPath
  1.1418+1 -0  ports/sysutils/Makefile
  1.1   +29 -0 ports/sysutils/bsdinfo/Makefile (new)
  1.1   +2 -0  ports/sysutils/bsdinfo/distinfo (new)
  1.1   +7 -0  ports/sysutils/bsdinfo/pkg-descr (new)
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/security/sudo Makefile

[Wesley Shields]

wxs 2012-06-21 13:01:13 UTC

  FreeBSD ports repository

  Modified files:
security/sudoMakefile 
  Log:
  Fix typo.
  
  PR: ports/169284
  Submitted by:   From: Bryan Drewery br...@shatow.net
  
  Revision  ChangesPath
  1.149 +1 -1  ports/security/sudo/Makefile
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/x11/etoile Makefile

[Wesley Shields]

wxs 2012-06-21 16:43:20 UTC

  FreeBSD ports repository

  Modified files:
x11/etoile   Makefile 
  Log:
  Adjust deprecation message as discussed on ports@.
  
  Revision  ChangesPath
  1.22  +1 -1  ports/x11/etoile/Makefile
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/sysutils/bsdconfig Makefile distinfo

[Wesley Shields]

wxs 2012-06-21 16:58:23 UTC

  FreeBSD ports repository

  Modified files:
sysutils/bsdconfig   Makefile distinfo 
  Log:
  Update to 0.7.1.
  
  PR: ports/169280
  Submitted by:   dteske@ (maintainer)
  
  Revision  ChangesPath
  1.2   +2 -2  ports/sysutils/bsdconfig/Makefile
  1.2   +4 -4  ports/sysutils/bsdconfig/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/sysutils/bsdconfig Makefile distinfo

[Wesley Shields]

wxs 2012-06-22 01:46:16 UTC

  FreeBSD ports repository

  Modified files:
sysutils/bsdconfig   Makefile distinfo 
  Log:
  Update to 0.7.2.
  
  When editing a user's password or account expiration property, choosing 
cancel
  or pressing ESC while editing the value manually would cause the value to be
  blanked rather than preserved. This has been fixed and pressing ESC (or
  choosing cancel) now preserves the value as expected.
  
  Executing bsdconfig foo when LANG is set to EN_US.ISO8859-1 produces a
  non-i18n-compatible error message: bsdconfig: foo: not found (when it should
  produce: bsdconfig: foo: NOT FOUND). This has been fixed by adding the
  appropriate i18n messages and changing the code to use them.
  
  Executing bsdconfig -h when LANG is set to an unknown language (for which
  there are no bsdconfig localized language files), the output did not display
  appropriately. This has been fixed.
  
  Executing bsdconfig timezone -h (for example) when LANG is set to an unkown
  language had similar issues to the above.
  
  PR: ports/169306
  Submitted by:   dteske@
  
  Revision  ChangesPath
  1.3   +2 -2  ports/sysutils/bsdconfig/Makefile
  1.3   +4 -4  ports/sysutils/bsdconfig/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/emulators/dynagen Makefile pkg-deinstall pkg-install pkg-plist ports/emulators/dynagen/files patch-setup.py

[Wesley Shields]

wxs 2012-06-22 01:49:00 UTC

  FreeBSD ports repository

  Modified files:
emulators/dynagenMakefile 
emulators/dynagen/files patch-setup.py 
  Added files:
emulators/dynagenpkg-deinstall pkg-install 
  Removed files:
emulators/dynagenpkg-plist 
  Log:
  Fix RUN_DEPENDS.
  Add LICENSE.
  Switch to PLIST_FILES.
  
  PR: ports/168937
  Submitted by:   Pavel I Volkov pavelivol...@googlemail.com (maintainer)
  
  Revision  ChangesPath
  1.17  +49 -18ports/emulators/dynagen/Makefile
  1.3   +3 -4  ports/emulators/dynagen/files/patch-setup.py
  1.1   +6 -0  ports/emulators/dynagen/pkg-deinstall (new)
  1.1   +4 -0  ports/emulators/dynagen/pkg-install (new)
  1.7   +0 -78 ports/emulators/dynagen/pkg-plist (dead)
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

Re: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)

[Wesley Shields]

On Thu, Jun 21, 2012 at 11:40:15AM +, Michael Scheidell wrote:
 Sorry if I confused you with more than one  comment in one email. Next
 time I will send multiple emails with just one comment in each  email.
 I hope this helps.

Please try to be civil.

 -Original message-
 From: Mikhail T. mi+t...@aldan.algebra.com
 To: Michael Scheidell scheid...@freebsd.org
 Cc: freebsd-ports@freebsd.org freebsd-ports@freebsd.org
 Sent: Thu, Jun 21, 2012 11:32:59 GMT+00:00
 Subject: etoile ports dropped for strange reason (Re: freebsd-ports Digest, 
 Vol 474, Issue 7)
 
 On 21.06.2012 06:54, Michael Scheidell wrote:
 you are more then welcome to adopt them.
 Is the above REALLY, what API no longer supported means these days?
 -mi

The release in our ports tree is not recommended upstream anymore.
Quoting the upstream webpage: Take note they [old releases] won't
usually work with recent LLVM and GNUstep releases.

As the port is unmaintained and the version in our tree is not
recommended for use anymore it was deprecated. Sure, the reason could be
more clear. I will commit an update that reflects that to make it more
clear.

If you would like to see this port remain in the tree I recommend
adopting it and keeping it in working order (first step is to update it
to a recommended release).

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)

[Wesley Shields]

On Thu, Jun 21, 2012 at 12:27:04PM -0400, Mikhail T. wrote:
 On 21.06.2012 11:37, Wesley Shields wrote:
  The release in our ports tree is not recommended upstream anymore.
  Quoting the upstream webpage: Take note they [old releases] won't
  usually work with recent LLVM and GNUstep releases.
 Do we have these recent LLVM and GNUstep releases in the tree already?

In base, yes I believe so. Older, yet still supported FreeBSD releases,
would require using what's in the ports tree. Please don't take my word
on any of this as it was only what I read from their webpage as I don't
use any of these ports.

  As the port is unmaintained and the version in our tree is not
  recommended for use anymore it was deprecated. Sure, the reason could be
  more clear. I will commit an update that reflects that to make it more
  clear.
 
  If you would like to see this port remain in the tree I recommend
  adopting it and keeping it in working order (first step is to update it
  to a recommended release).
 The chance of a new maintainer stepping up may increase, if the
 deprecation message states something like Update to a new release
 is required... And, of course, a more generous expiration time would
 be needed. These ports are a legion...

I will update the deprecation message shortly. I will also update the
expiration date if someone is willing to at least verbally commit to
working on an update. I see no point in pushing the expiration date back
if nobody is going to do the work to keep it properly maintained. If
someone steps up after the port has been removed I will happily pull it
out of the Attic for that person.

-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

cvs commit: ports/sysutils Makefile ports/sysutils/bsdconfig Makefile distinfo pkg-descr

[Wesley Shields]

wxs 2012-06-20 16:58:13 UTC

  FreeBSD ports repository

  Modified files:
sysutils Makefile 
  Added files:
sysutils/bsdconfig   Makefile distinfo pkg-descr 
  Log:
  bsdconfig is a robust utility for configuring/managing various aspects of the
  FreeBSD Operating System. Feature-highlights include (but are not limited to):
- Modular, stable, efficient and i18n-compatible.
- Easily maintained/extendable sh(1) source/syntax.
- Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog).
- rc.conf(5) configuration/management based on sysutils/sysrc
- Timezone configuration based on sysutils/tzdialog
- Networking management based on sysutils/host-setup
  
  WWW: http://druidbsd.sourceforge.net/
  
  PR: ports/169257
  Submitted by:   dteske@
  
  Revision  ChangesPath
  1.1417+1 -0  ports/sysutils/Makefile
  1.1   +227 -0ports/sysutils/bsdconfig/Makefile (new)
  1.1   +4 -0  ports/sysutils/bsdconfig/distinfo (new)
  1.1   +10 -0 ports/sysutils/bsdconfig/pkg-descr (new)
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/security/sudo Makefile

[Wesley Shields]

wxs 2012-06-19 01:38:09 UTC

  FreeBSD ports repository

  Modified files:
security/sudoMakefile 
  Log:
  Add option to enable OPIE support (off by default). [1]
  While here, convert to new-style options.
  
  PR: ports/168812 [1]
  Submitted by:   Zak Blacher zblac...@sandvine.com [1]
  
  Revision  ChangesPath
  1.148 +28 -19ports/security/sudo/Makefile
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/net/libpcap Makefile distinfo

[Wesley Shields]

wxs 2012-06-19 01:38:43 UTC

  FreeBSD ports repository

  Modified files:
net/libpcap  Makefile distinfo 
  Log:
  Update to 1.3.0.
  While here convert to new-style options.
  
  Revision  ChangesPath
  1.27  +14 -5 ports/net/libpcap/Makefile
  1.13  +2 -2  ports/net/libpcap/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/net/tcpdump Makefile distinfo

[Wesley Shields]

wxs 2012-06-19 01:39:43 UTC

  FreeBSD ports repository

  Modified files:
net/tcpdump  Makefile distinfo 
  Log:
  Update to 4.3.0.
  Don't specify major version for libpcap dependency.
  While here convert to new-style options.
  
  Revision  ChangesPath
  1.32  +24 -19ports/net/tcpdump/Makefile
  1.13  +2 -2  ports/net/tcpdump/distinfo
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/security/vuxml vuln.xml

[Wesley Shields]

wxs 2012-06-13 20:16:44 UTC

  FreeBSD ports repository

  Modified files:
security/vuxml   vuln.xml 
  Log:
  Update 55587adb-b49d-11e1-8df1-0004aca374af with more information.
  
  Revision  ChangesPath
  1.2735+20 -4 ports/security/vuxml/vuln.xml
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/security/vuxml vuln.xml

[Wesley Shields]

wxs 2012-06-12 15:27:21 UTC

  FreeBSD ports repository

  Modified files:
security/vuxml   vuln.xml 
  Log:
  Document mantis vulnerabilities. The information is a bit light on details
  but I'm unable to track down better.
  
  PR: ports/168984
  Submitted by:   Dan Langille d...@langille.org
  
  Revision  ChangesPath
  1.2734+27 -1 ports/security/vuxml/vuln.xml
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org

cvs commit: ports/databases/mantis Makefile distinfo pkg-plist

[Wesley Shields]

wxs 2012-06-13 01:39:39 UTC

  FreeBSD ports repository

  Modified files:
databases/mantis Makefile distinfo pkg-plist 
  Log:
  Update to 1.2.11.
  
  PR: ports/168983
  Submitted by:   Dan Langille d...@langille.org (maintainer)
  Security:   55587adb-b49d-11e1-8df1-0004aca374af
  
  Revision  ChangesPath
  1.31  +1 -1  ports/databases/mantis/Makefile
  1.24  +2 -2  ports/databases/mantis/distinfo
  1.21  +62 -20ports/databases/mantis/pkg-plist
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org