file_state m_time

[bstullkid]

Some javascript/style in this post has been disabled (why?)

Hello,

 

I was wondering why the oval implementation insists that the date for m_time, c_time, a_time be specified as a 64bit value instead of in a format such as mm/dd/yyy. I’ve noticed that m_time,c_time are never used in any windows oval defintions which is probably because people don’t feel like converting file dates as they appear in windows to that single 64bit integer value. I’m working on an oval interpreter that collects data from remote machines which is why I bring this up because collecting a date from a file at a remote location is quick and easy which requires no file download. On the other hand, getting a file version remotely requires downloading the file from the target machine.

 

Maybe something could be added to specify whether the m_time,c_time,a_time is a value or a date string and people may choose to use it more.

Example:

 

<m_time type=”date_string”>mm/dd/yyy</m_time>

<m_time type=”value”>1234512123142</m_time>

 

-Brian

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email] unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

[Jeff Saxton-2]

Some javascript/style in this post has been disabled (why?)

Unix and POSIX-compliant systems implement time_t as an integer or real-floating type ^[1] (typically a 32- or 64-bit integer) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds).

 

---

From: Stull, Brian [[hidden email]]
Sent: Tuesday, October 27, 2009 3:41 PM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] file_state m_time

Hello,

 

I was wondering why the oval implementation insists that the date for m_time, c_time, a_time be specified as a 64bit value instead of in a format such as mm/dd/yyy. I’ve noticed that m_time,c_time are never used in any windows oval defintions which is probably because people don’t feel like converting file dates as they appear in windows to that single 64bit integer value. I’m working on an oval interpreter that collects data from remote machines which is why I bring this up because collecting a date from a file at a remote location is quick and easy which requires no file download. On the other hand, getting a file version remotely requires downloading the file from the target machine.

 

Maybe something could be added to specify whether the m_time,c_time,a_time is a value or a date string and people may choose to use it more.

Example:

 

<m_time type=”date_string”>mm/dd/yyy</m_time>

<m_time type=”value”>1234512123142</m_time>

 

-Brian

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email] unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

[bstullkid]

Some javascript/style in this post has been disabled (why?)

Yes, but it would be a lot easier on the user writing the vulnerability check to specify file dates in mm/dd/yyyy format.

 

---

From: Jeff Saxton [mailto:[hidden email]]
Sent: Tuesday, October 27, 2009 6:02 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time

 

Unix and POSIX-compliant systems implement time_t as an integer or real-floating type ^[1] (typically a 32- or 64-bit integer) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds).

 

---

From: Stull, Brian [[hidden email]]
Sent: Tuesday, October 27, 2009 3:41 PM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] file_state m_time

Hello,

 

I was wondering why the oval implementation insists that the date for m_time, c_time, a_time be specified as a 64bit value instead of in a format such as mm/dd/yyy. I’ve noticed that m_time,c_time are never used in any windows oval defintions which is probably because people don’t feel like converting file dates as they appear in windows to that single 64bit integer value. I’m working on an oval interpreter that collects data from remote machines which is why I bring this up because collecting a date from a file at a remote location is quick and easy which requires no file download. On the other hand, getting a file version remotely requires downloading the file from the target machine.

 

Maybe something could be added to specify whether the m_time,c_time,a_time is a value or a date string and people may choose to use it more.

Example:

 

<m_time type=”date_string”>mm/dd/yyy</m_time>

<m_time type=”value”>1234512123142</m_time>

 

-Brian

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email] unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email] unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

[Andrew Buttner]

You bring up a good point.  We have always had to balance things like this.  The goal in OVAL has been to represent the data in the XML in the same format as we would get from the system.  This keeps us from having OVAL forced to pick the 'most useful' data representation.  I agree that this might not always be the most readable solution for the user.  But we also have always expected users to work at a level above the XML using tools to do content creation etc.  The XML is just the foundational data encoding.  I hope that your issue is solved by an OVAL Editor that allows the user to enter in data in the mm/dd/yyyy format and transforms that behind the scenes into OVAL XML.

Thanks
Drew

>-----Original Message-----
>From: Stull, Brian [mailto:[hidden email]]
>Sent: Tuesday, October 27, 2009 6:07 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time
>
>Yes, but it would be a lot easier on the user writing the vulnerability check to
>specify file dates in mm/dd/yyyy format.
>
>
>
>________________________________
>
>From: Jeff Saxton [mailto:[hidden email]]
>Sent: Tuesday, October 27, 2009 6:02 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time
>
>
>
>Unix <http://en.wikipedia.org/wiki/Unix>  and POSIX-compliant systems
><http://en.wikipedia.org/wiki/POSIX>  implement time_t as an integer or real-floating
><http://en.wikipedia.org/wiki/Floating_point>  type [1]
><http://en.wikipedia.org/wiki/Time_t#cite_note-0>  (typically a 32- or 64-bit
>integer) which represents the number of seconds since the start of the Unix epoch
><http://en.wikipedia.org/wiki/Unix_epoch> : midnight
><http://en.wikipedia.org/wiki/Midnight>  UTC <http://en.wikipedia.org/wiki/UTC>  of
>January 1 <http://en.wikipedia.org/wiki/January_1> , 1970
><http://en.wikipedia.org/wiki/1970>  (not counting leap seconds
><http://en.wikipedia.org/wiki/Leap_seconds> ).
>
>
>
>________________________________
>
>From: Stull, Brian [[hidden email]]
>Sent: Tuesday, October 27, 2009 3:41 PM
>To: [hidden email]
>Subject: [OVAL-DEVELOPER-LIST] file_state m_time
>
>Hello,
>
>
>
>I was wondering why the oval implementation insists that the date for m_time, c_time,
>a_time be specified as a 64bit value instead of in a format such as mm/dd/yyy. I've
>noticed that m_time,c_time are never used in any windows oval defintions which is
>probably because people don't feel like converting file dates as they appear in
>windows to that single 64bit integer value. I'm working on an oval interpreter that
>collects data from remote machines which is why I bring this up because collecting a
>date from a file at a remote location is quick and easy which requires no file
>download. On the other hand, getting a file version remotely requires downloading the
>file from the target machine.
>
>
>
>Maybe something could be added to specify whether the m_time,c_time,a_time is a value
>or a date string and people may choose to use it more.
>
>Example:
>
>
>
><m_time type="date_string">mm/dd/yyy</m_time>
>
><m_time type="value">1234512123142</m_time>
>
>
>
>-Brian
>
>To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-
>DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-
>[hidden email] unsubscribe, send an email message to
>[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.
>If you have difficulties, write to [hidden email].
>
>To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-
>DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-
>[hidden email] unsubscribe, send an email message to
>[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.
>If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

[Richard_Whitehurst]

Drew,

First, the problem for an OVAL editor is that there is nothing in OVAL to help an editor "realize" that a value is a date or duration, and even if there were, there is still nothing to indicate the scale should be nanoseconds, minutes, days or years.  I have no problem with OVAL having these values in their native types, but I believe it is incumbent on the OVAL check writer to use the oval functions to convert "user friendly" formats into the native types, where possible.  (If some standard conversions can't be performed using the capabilities of the current OVAL spec, we should probably consider adding some date/time/duration conversion functions.)

I don't have a problem with OVAL "professionals" needing to understand the native formats.

However, if we want to increase the adoption of OVAL to include those who are not necessarily mandated to use it, we should give serious consideration to making the language understandable to the OVAL writers, and to making it user friendly to those who are consumers, e.g., the administrators who must tailor values to match their organizational needs. In particular, it is very user unfriendly to require someone who is *tailoring* a benchmark to have to convert "2 weeks" into the appropriate number of nanoseconds, or to convert an date to the number of milliseconds since Jan. 1, 1970.

Dick Whitehurst


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, October 28, 2009 4:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time

You bring up a good point.  We have always had to balance things like this.  The goal in OVAL has been to represent the data in the XML in the same format as we would get from the system.  This keeps us from having OVAL forced to pick the 'most useful' data representation.  I agree that this might not always be the most readable solution for the user.  But we also have always expected users to work at a level above the XML using tools to do content creation etc.  The XML is just the foundational data encoding.  I hope that your issue is solved by an OVAL Editor that allows the user to enter in data in the mm/dd/yyyy format and transforms that behind the scenes into OVAL XML.

Thanks
Drew

>-----Original Message-----
>From: Stull, Brian [mailto:[hidden email]]
>Sent: Tuesday, October 27, 2009 6:07 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time
>
>Yes, but it would be a lot easier on the user writing the vulnerability check to
>specify file dates in mm/dd/yyyy format.
>
>
>
>________________________________
>
>From: Jeff Saxton [mailto:[hidden email]]
>Sent: Tuesday, October 27, 2009 6:02 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] file_state m_time
>
>
>
>Unix <http://en.wikipedia.org/wiki/Unix>  and POSIX-compliant systems
><http://en.wikipedia.org/wiki/POSIX>  implement time_t as an integer or real-floating
><http://en.wikipedia.org/wiki/Floating_point>  type [1]
><http://en.wikipedia.org/wiki/Time_t#cite_note-0>  (typically a 32- or 64-bit
>integer) which represents the number of seconds since the start of the Unix epoch
><http://en.wikipedia.org/wiki/Unix_epoch> : midnight
><http://en.wikipedia.org/wiki/Midnight>  UTC <http://en.wikipedia.org/wiki/UTC>  of
>January 1 <http://en.wikipedia.org/wiki/January_1> , 1970
><http://en.wikipedia.org/wiki/1970>  (not counting leap seconds
><http://en.wikipedia.org/wiki/Leap_seconds> ).
>
>
>
>________________________________
>
>From: Stull, Brian [[hidden email]]
>Sent: Tuesday, October 27, 2009 3:41 PM
>To: [hidden email]
>Subject: [OVAL-DEVELOPER-LIST] file_state m_time
>
>Hello,
>
>
>
>I was wondering why the oval implementation insists that the date for m_time, c_time,
>a_time be specified as a 64bit value instead of in a format such as mm/dd/yyy. I've
>noticed that m_time,c_time are never used in any windows oval defintions which is
>probably because people don't feel like converting file dates as they appear in
>windows to that single 64bit integer value. I'm working on an oval interpreter that
>collects data from remote machines which is why I bring this up because collecting a
>date from a file at a remote location is quick and easy which requires no file
>download. On the other hand, getting a file version remotely requires downloading the
>file from the target machine.
>
>
>
>Maybe something could be added to specify whether the m_time,c_time,a_time is a value
>or a date string and people may choose to use it more.
>
>Example:
>
>
>
><m_time type="date_string">mm/dd/yyy</m_time>
>
><m_time type="value">1234512123142</m_time>
>
>
>
>-Brian
>
>To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-
>DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-
>[hidden email] unsubscribe, send an email message to
>[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.
>If you have difficulties, write to [hidden email].
>
>To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-
>DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-
>[hidden email] unsubscribe, send an email message to
>[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.
>If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].